Frage von joerg eichhorn:
Hello,
I have an uncompressed avi (wise background, then a
light gray rectangle, the black writing) is available. if I have it
with an MPEG-encoder (tried with ligos premiere plugin and TMPGEnc)
an MPEG-2 for a DVD, all the white stuff gray.
how can I fix? I must predict the color in avi (24bit
rgb) Convert?
many thanks, joerg gruss Eichhorn
Antwort von Heiko Nocon:
Eichhorn joerg wrote:
> I have an uncompressed avi (wise background, then a
> Light gray rectangle, the black writing) is available.
What is "white" and what is "gray"? That is the crux of the matter.
> How can I fix? I must predict the color in avi (24bit
> Rgb) Convert?
This would purely garnix, because precisely at this step (the
MPEG encoder implicitly makes anyway) is likely the cause of the problem
lie. Your RGB white is just white _zu_ for the YUV colorspace. Or
in other words: Have your RGB "gray" is when it is in the
YUV color space conversion, white or almost white, at least.
Ergo: you must be already in the RGB color space to ensure that "Gray" a little
darker, so after the conversion to the YUV color space, a
visible difference between "gray gray" and "white gray title".
Sowas goes eg with the VirtualDub filter "levels".
Antwort von joerg eichhorn:
Nocon Heiko wrote:
> Joerg Eichhorn wrote:
>> How can I fix? I must predict the color in avi (24bit
>> Rgb) Convert?
>
> This would be purely garnix, because precisely at this step (the
> MPEG encoder implicitly makes anyway) is likely the cause of the problem
> Lie. Your RGB white is just white _zu_ for the YUV colorspace. Or
> In other words: Have your RGB "gray" is when it is in the
> YUV colorspace conversion, white or nearly white.
if it is my light gray white made, I could live with that
I download it regulates - or virtual dub to adjust the gamma.
my problem is that if I am in the m2v player - vlc here
chart, the white area with 30% more black outputs.
danke, gruss joerg Eichhorn
Antwort von Heiko Nocon:
Eichhorn joerg wrote:
> My problem is that if I am in the m2v player - vlc here
> Watch, the white area with 30% more black outputs.
Exactly when that happens (nichtsaturierender) conversion, if the
RGB color in the YUV color space is no longer manner. A very
classic wrap-around effect.
Decrease the contrast and brightness of the original and a bit of
Effect will disappear, which you can believe me. Alternatively
you could be a saturation synonymous RGB> YUV converter used. That
But the worst solution, because then it just means that
Gray and white after converting both to be white. That
Result looks like a significantly overexposed Still image.
What you filter to reduce brightness and contrast of
use is fairly unimportant. The only important thing is that the filtering
already in the RGB color space is done and not after the
YUV conversion. Then the shit already happened and
no filter in the world can be a little more change.
Antwort von Andre Beck:
Heiko Nocon
writes:
> Joerg Eichhorn wrote:
>
>> My problem is that if I am in the m2v player - vlc here
>> Watch the white area with 30% more black outputs.
Have you tried other players?
> Exactly what happens when (nichtsaturierender) conversion, if the
> RGB color in the YUV color space is no longer manner. A very
> Classic wrap-around effect.
And here we are talking of pure grayscale, which must be depicted.
It is not true that in an ultra-white RGB exist. The Grays
So like when converting something s.Resolutionverlieren because they
digital something together, but a Wrap is really gross
impossible, unless the RGB-YUV conversion is gecodet of laymen.
> Reduce the contrast and brightness of the original and a bit of
> Effect will disappear, which you can believe me. Alternatively
> You could be a saturation synonymous RGB> YUV converter used. That
> Is the worst solution, because then it just means that
> Light gray and white after converting both to be white. That
> Result looks like a significantly overexposed Still image.
A correct converter for MPEG CCIR.601 after but should not
saturieren did wrapper, but * * Scale: RGB (0,0,0) is
to YUV (16 ,...), RGB (255,255,255) is to YUV (235 ,...) and everything else
plays out in between or in the other dimensions.
> What is you filter for the reduction of brightness and contrast
> Use, is quite unimportant. The only important thing is that the filtering
> Already in the RGB color space is done and not after the
> YUV conversion. Then the shit already happened and
> No filter in the world can be a little more change.
I can not understand. Either one fixes the converter after
YUV or you let it completely. In RGB artificially limits implement
expect that there do not exist, it seems to me absurd. Aggravated
come here no more than add, if the MPEG encoder with no RGB,
but with YUV feeds: You can not auto open
even if the input to the color space after CCIR.601 must be scaled
or if the already happened - it must be him, depending on the
Circumstances indicate. If this message bottle, ie the YUV --
Input is unscaled, the encoder but thinks he would be a scaled, then
we come into the area where Black and Ultra Ultra White arise.
They are synonymous, but not per se s.Wrappen maximum in a bad
implemented player. A good player will be implemented either
real output (as a voltage level which is lower or higher
, than the standard level for black and white), or, if this
can not saturieren (PC Player software, which renders an overlay).
My guess is therefore that the Urposter a combination of
incorrectly encoded MPEG (where his ultra-white to be white) and
Player incorrectly implemented (neither clipped nor saturated
but wrapped) observed in action.
--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <--
Antwort von Heiko Nocon:
Andre Beck wrote:
> And here we are talking of pure grayscale, which must be depicted.
Not necessarily. It simply depends on the scaling factor
Conversion from.
> It is not true that in an ultra-white RGB exist. The Grays
> Like to convert something that is s.Resolutionverlieren because they
> Digital something together, but a Wrap is really gross
> Impossible, unless the RGB-YUV conversion is gecodet of laymen.
No.. Only the strunzdumme of the converter is always runterskalieren and
so that in 95 or even 99% percent of cases, quality senseless destruction.
Almost no "natural" video using the RGB color space as far from that
a scaling for the YUV conversion necessary. If course
synonymous because natural video almost always from YUV sources,
at least as far as the SOHO scope.
> A correct converter for MPEG CCIR.601 after but should not
> Saturieren did wrapper, but * * Scale
Eben is with the probability of that senseless destruction
of information. The correct converter should, whenever possible,
neither scale nor saturieren or wrapper. Just exactly this behavior
which allows almost lossless color space conversions. Only
when it's due to excess loss of range does not work,
then the converter must necessarily do anything. Wrapping comes
of course only for a single purpose in question: the user
unmistakably clear to show that he must try something else.
> Can I do not understand.
Why not? When the YUV conversion wrapped (and did it
obvious), then afterwards nothing more. What is not
understand?
> Either one fixes the converter after
> YUV or it can be quite.
Ahem ... But you sure is clear that the reduction of contrast
to RGB-Page that is exactly what a scaling YUV Converter
synonymous ultimately makes, huh? But even with the difference that by
manual optimization of brightness and contrast has the possibility
the intersection of conversion and thus to maximize the
To minimize conversion losses. A fixed scaling
however, is not more than coincidentally, the optimal result. This is
really primitive mathematics, which you need but you certainly
not to explain.
The only advantage is a fixed scale, so that under no
Illegal color may occur. This is such a
DAU-fit solution. Good of them but they will not.
Antwort von Andre Beck:
Heiko Nocon writes:
> Andre Beck wrote:
>
>> And here we are talking of pure grayscale, which must be depicted.
>
> Not necessarily. It simply depends on the scaling factor
> Conversion from.
The set. It is clear what s.Ende white and black for
Coordinates in color space is needed, so you can factor
not just arbitrarily change. That would correspond to an arbitrary
Modification of black-and white level of the video, a manipulation which
can not exceed itself if it wants * content *, which
But IMO no simple format converter leaves.
>> It is not true that in an ultra-white RGB exist. The Grays
>> Like to convert something that is s.Resolutionverlieren because they
>> Digital something together, but a Wrap is really gross
>> Impossible, unless the RGB-YUV conversion is gecodet of laymen.
>
> No.. Only the strunzdumme of the converter is always runterskalieren and
> So that in 95 or even 99% percent of cases, quality pointless
> Destroy. Almost no "natural" video using the RGB color space so
> Far from that for a scaling YUV conversion necessary
> Would be. Is of course synonymous that natural video almost always from
> YUV sources, at least in the SOHO sector is concerned.
You want to say, when YUV2RGB conversion of material with
known origin from a CCIR.601 area would already generated RGB,
the color does not take advantage? Sorry, I do not think so, that would be
stupid (which, of course, by no means excludes that software exists
the wrong, on the contrary). I expect that in RGB and white
(255,255,255) is located. There is nothing defined. For YUV
Unfortunately, the situation is that a YUV not committed s.es
the entire range advantage, so white at Y% 5, or whether
Y is already # 5 as a white view. But this is the only synonymous
Uncertainty, the man with a switch s.MPEG encoder can eradicate.
We can discuss such a switch are synonymous
to leave if the input is RGB and you know that one RGB
Material consumption, which is of limited YUV CCIR without scaling
on the full Farbwürfel has changed. To other people's mistakes
Nachzurennen software, but it is apparently necessary.
>> A correct converter for MPEG CCIR.601 after but should not
>> Saturieren did wrapper, but * * Scale
>
> That is with the probability of that senseless destruction
> Of information. The correct converter should, whenever possible,
> Neither scale nor saturieren or wrapper.
In other words, it is an arbitrary change of image brightness
Making? No, thank you.
> Just exactly this behavior that allows almost lossless
> Colorspace conversions.
A conversion of RGB to YUV-CCIR.601 can not lossless
be. This target with manipulation of the material in a direction
unnaturally high brightness and color but still achieve
appears to want me premature. If anything, then the
Converter with a black-and white point adjustment to go,
so I scaling the magnitude of himself. Almost
lossless color conversions you get only with the full range
YUV, so it works out and implements the arithmetic practicable
in at least 16 bit and with saturation before converting back
in the usual 8-bit samples.
> Only if it's any loss due to overrun
> Of range does not work, then the converter must necessarily
> Do something. Wrapping comes naturally only for a
> Single purpose in question: the user unmistakably clear to show
> That he must try something else.
Hmpf. You can bug synonymous nice talk. A whole platform
live it. Good, it would be nice, s.einem such a switch converter
for the test to have, to a value range exceedance
with a false color makes unmistakably identified. But something is a
explicitly anzuschaltendes feature. We are talking here of a rather
PC software typical chain of errors that later as a feature
reinterpret it irge
