147 replies to this topic

[Erik Slagter]

from my point of vision we miss some user changeable option to able choose diffrernt upscaling methods
like vertical pixels x2 or x3
horisontal x2; x3; keepAspectratio

How do you mean? Video scalers use n-order tap filters, which resemble conversion to analogue, analogue bandwidth reduction and then conversion to digital again (although with a lot less distortion then with actual conversion to-from analogue). You wouldn't want to use a discrete scaling, that looks horrible!

another way to destroy SD quality is send received 4:3 SD through HDMI SD mode with added side blackbars,
picture then downscaled with pixels lose ~20%
this war i have won DMM Board » Enigma 2 - Feature Requests » [SOLVED 99%] DVI(HDMI) can't handle most used aspectratio

I don't exactly understand what you mean. The stb adds black borders to resolve the aspect ratio of the source to that of the destination, is that what you mean? Over hdmi/dvi that's actually what you want, because most tv sets do not support aspect ratio metadata over hdmi, although it's defined in the standard.

I think the phenomenon that HD channels add black borders on 4:3 material is far more severe. These black borders are encoded, transmitted and take up valuable bits in the stream while they carry no information. H264 supports random aspect ratios and also all stb's I know can scale these random aspect ratios to match the tv's, so technically there is no reason to use black borders in broadcast material.

[gorski]

another way to destroy SD quality is send received 4:3 SD through HDMI SD mode with added side blackbars,
picture then downscaled with pixels lose ~20%

This is what my BDCM DM/Ferrari 500 HD is doing badly and Sigma AZbug HD is handling it much better, for instance... You know, the two of them being side by side, from one to the other, the same settings in both, the same signal {TV or streaming from NAS etc.] - bleedin' obvious...

[gorski]

You wouldn't want to use a discrete scaling, that looks horrible!

Erik, sorry, I can't help it: are you using your eyes now as a sole judge?!?

technically there is no reason to use black borders in broadcast material.

Thanx! Could you expand a bit more, as I would like to learn a bit more... Scaling here, changing the aspect from 4:3 to 16:9 etc., is something not done very well by BDCM, from my point of view - or have I overlooked something and I should try it differently?

I mean, if you try that with E2 settings in any image with DMM/Ferrari - it looks horrible, when changed that way, by the STB! As opposed to Sigma's AZbug, for instance.

[Erik Slagter]

You wouldn't want to use a discrete scaling, that looks horrible!

Erik, sorry, I can't help it: are you using your eyes now as a sole judge?!?

All of the time I am trying to explain that perception is not a good base to start quality comparison from. So, no that's not with "my eyes". If you make this remark, you obviously have never seen discrete scaling, because you would agree. This has nothing to do with better or worse quality, the result is hardly recognisable. Be glad nobody has been using it for a long time. I've only seen it on ancient laptops.

technically there is no reason to use black borders in broadcast material.

Thanx! Could you expand a bit more, as I would like to learn a bit more... Scaling here, changing the aspect from 4:3 to 16:9 etc., is something not done very well by BDCM, from my point of view - or have I overlooked something and I should try it differently?
I mean, if you try that with E2 settings in any image with DMM/Ferrari - it looks horrible, when changed that way, by the STB! As opposed to Sigma's AZbug, for instance.

My remark has nothing to do with that.

[gorski]

Erik, sorry, I can't help it: are you using your eyes now as a sole judge?!?

All of the time I am trying to explain that perception is not a good base to start quality comparison from. So, no that's not with "my eyes". If you make this remark, you obviously have never seen discrete scaling, because you would agree. This has nothing to do with better or worse quality, the result is hardly recognisable. Be glad nobody has been using it for a long time. I've only seen it on ancient laptops.

In other words, now you are using only your eyes and mentioning "whoever sees it must agree with me" 'argument'... Which is something some other people have mentioned regarding this very topic but then you dismissed it out of hand...

In fact, you're jumping into your own stomach and quite hard, with this argument...

technically there is no reason to use black borders in broadcast material.

My remark has nothing to do with that.

Care to expand, please?

[Erik Slagter]

In other words, now you are using only your eyes and mentioning "whoever sees it must agree with me" 'argument'... Which is something some other people have mentioned regarding this very topic but then you dismissed it out of hand...

IF you had known what you are talking about (discrete vs. tap filter scalers and how it works) THEN you would agree with me. This is really not an issue of perception, it's not something different people will disagree upon, and also all PSNR measurements will agree, discrete scaling yields terrible results. There is a simple way to see what it's like; on your computer, turn off all kinds of anti-aliasing for font rendering and enjoy. There is one exception, and that is when the destination resolution is an exact multiple of pixels of the source resolution, then the result will be okay (e.g. 960x540 to 1920x1080). But still it won't be better as using tap filters, so there is no reason to use it, never. If you still disagree, I'd be tempted to suggest you ask broadcom politely to implement a discrete scaler and go and enjoy the picture quality.

In fact, you're jumping into your own stomach and quite hard, with this argument...

Well, if you say so...

technically there is no reason to use black borders in broadcast material.

My remark has nothing to do with that.

Care to expand, please?

How about reading what I wrote? It's already there!

Edited by Erik Slagter, 29 May 2012 - 14:18.

[gorski]

Hmmm, nope, I don't buy it.

Here is the challenge: either you really show us the scientific side, which is universal, obliging etc. OR you are, after all is said and done, relying on your eyes, just covering it in a thin layer of what you "know" is going on underneath.,,..

Therein lies the problem: if you put the "measurements" out in the open there may be a fallout to suffer... We may see that there are not many ways you can do this, you see... There isn't much there, is it? So, we are still not seeing anything that is truly measurable, universal and not prone to "magic", where hand is faster than the eye and it's all but an illusion...

As things stand, and here I stand by my charge that you're jumping into your own stomach, [and the more this is going on without anything really measurable, the more this is apparent to us all] you are ultimately relying on your eyes, to "prove" what you "know" from the technical side...

But you know, humans only have human eyes...

P.S. I read carefully but your explanations, to me, do not seem all that straight-forward and I am not alone in that feeling of "not exactly being convinced", including some from OpenPLi Team... In fact, they also [politely, like most of us] told you things are not black and white...

Edited by gorski, 29 May 2012 - 19:14.

[Erik Slagter]

This proves you do not understand the principle of discrete pixel scaling on non-trivial resolution ratio's vs. resampling. Fine by me...

[gorski]

Of course I do not. I told you myself I am not from technical sciences. But in this case it is not me who is pig-headed, missing the point. An obvious one, at that, at least to me and a few others in this debate.

Moreover, being a phonetician [and a philosopher by formal education], I do know a few things about senses and relationship to our interpreting powers and through it the limit of our senses...

Ultimately, however, no amount of talking, debating and "knowing" on a theoretical level, can change certain characteristics of our perception. You can know tech specs all you want but in the end...

I am not saying that you are necessarily wrong just because you are at the extreme wing of the debate, in your puritan stance. Not at all. At the end of the day, some day, we all might have to say you were right and we were all wrong. It's just that in this case, I simply think you are stretching it beyond all limits, with your rigid views on the matter...

[Erik Slagter]

...

Edited by Erik Slagter, 29 May 2012 - 19:33.

[gorski]

Btw, where are the documents on the measuring side of all this - in our hobby, please? Anyone? I would really like to see those.

In Phonetics I know of a few, shall we say, which explain our perception via a certain relationship between our ears and brains, which result in "hearing" something in a specific manner. So, we can manipulate the input to help a person of poor hearing to perceive something in a desired manner.

How is this [not] being done in the field of vision, how is somebody more acute than another and what influences one's perception of colours etc.? In relation to this debate, of course... I am genuinely interested. Thanx in advance!

[Erik Slagter]

The problem is that you're narrowing down the whole discussion to two varieties of scaling, one of which hasn't been used for about ten years, because it's too basic to be really useful, so one of the two is actually not relevant... at all... ALL hardware and software scalers are using resampling. This is a non-discussion.

It's like the first LCD screens on laptops. They were awful (no need to discuss that I think) but the current technology didn't allow for better quality. Same as for scaling. There is no need nowadays to use anything other than resampling.

[Erik Slagter]

So please now return to the original subject: difference in image processing between different SoC's. Whether the different "picture" is actually a quality improvement, or only perceived as being better quality, is interesting. One thing is sure, all of the image processing in a SoC takes places at the hardware level, so no driver can ever change that, contrary what keeps being suggested here.

Edited by Erik Slagter, 29 May 2012 - 19:39.

[gorski]

I have no idea how I am doing what you are charging me with... After all, you yourself tell me what I do not know, as I admitted that from the start. So, how am I doing what you are charging me with, if I do not know anything, technically speaking, on the issue? It is impossible to claim that, for crying out loud...

I do have a very good idea what I am charging you with, though - and let me tell you - you're not answering any of the charges and you are not giving us the grounds on which you are claiming what you are claiming with such vehemence... Which leads me to believe you are wanting to believe something, rather than really know and see these things to be true... Sounds hollow, without any scientific grounds for it, sorry...

[gorski]

So please now return to the original subject: difference in image processing between different SoC's.

Which we know exists. So, there is ground for agreeing, correct?

Whether the different "picture" is actually a quality improvement, or only perceived as being better quality, is interesting.

Indeed. Because, at the end of the day, we can only judge with our eyes, if something is different and whether it is better or not. We have no other way of doing it.

It's like audiophiles quoting to each other millions of specs which are imperceptible to our ears... In the end, we must hear and/or see and decide. No way out!

One thing is sure, all of the image processing in a SoC takes places at the hardware level, so no driver can ever change that, contrary what keeps being suggested here.

Really? Explain, please... I thought that there has to be an interaction of HW and SW at all levels... But I am a lay person, so... Take it easy on me, please....

[Erik Slagter]

I believe the troll has been fed well enough by now. No comment.

[schattenmann]

So please now return to the original subject: difference in image processing between different SoC's. Whether the different "picture" is actually a quality improvement, or only perceived as being better quality, is interesting. One thing is sure, all of the image processing in a SoC takes places at the hardware level, so no driver can ever change that, contrary what keeps being suggested here.

That's not correct. In my first post I've tried to summarize what I had read here so far and I also was asking question / thinking loudly and in the end it was about hardware as well:

[...], so that everything becomes a matter of the hardware:

So why STB producers cannot modify the source codes to get a better picture quality ? Simply unskilled developers are the reason ?

Scaler = hardware. There is no software involved.[...]

which makes it hopeless to expect, that Broadcom boxes will ever have a "better" picture quality? Would the only solution be to use another chip? Is there a better one from Broadcom?

But everyone can read what you had answered to this... This dicussion doesn't have a chance to lead to something useful though, so I gave up on this.

[gorski]

Erik, I will take it as a sign of weakness, not potency and self-belief, from you, sorry...

I have tested for many a great writer in our hobby and this I have never seen...

My questions, suggestions and critical approaches were done in good faith!

{This must be the sorriest exit from a respectful debate ever...}

[buyukbang]

Can anyone contact with Ripper? I really want to know his schedule about the mentioned E2 plugin. I believe he is the only person who can change the direction of this topic to its original target.

[Hump]

Hmm, just read the discussion of the last couple of days. It's interesting, but doesn't get us anywhere near a solution/answer.

Fact is, that Kathrein UFS 910 with the original Software produces a much better PQ in SD AND HD than running it with e2, Neutrino or tiTan (I guess, they are all using the same drivers?)


Question is: Why is the PQ with UFS 910/Original Software so much better than with e2?

PS: The PQ of my et9x00/e2 is equivalent to the PQ of the UFS 910/e2.