Rundungs problem?

Kann diese Funktion ein Rundungs Problem verursachen?

Delphi-Quellcode:

			        for y := 0 to (imgH - 1) do

        begin

          for x := 0 to (imgW - 1) do

          begin

            if pBits.rgbReserved > 0 then

            begin

              AlphaCoef := (255 shl 8) div pBits.rgbReserved;

              pBits.rgbBlue := ((pBits.rgbBlue  * AlphaCoef) shr 8);

              pBits.rgbGreen := ((pBits.rgbGreen * AlphaCoef) shr 8);

              pBits.rgbRed := ((pBits.rgbRed * AlphaCoef) shr 8);

            end;

            inc(pBits);

          end;

        end;

wenn ja nehme ich besser

zusammenfalten · markieren

Delphi-Quellcode:

			        for y := 0 to (imgH - 1) do

        begin

          for x := 0 to (imgW - 1) do

          begin

            if pBits.rgbReserved > 0 then

            begin

              AlphaCoef := (255 shl 16) div pBits.rgbReserved;

              pBits.rgbBlue := ((pBits.rgbBlue  * AlphaCoef) shr 16);

              pBits.rgbGreen := ((pBits.rgbGreen * AlphaCoef) shr 16);

              pBits.rgbRed := ((pBits.rgbRed * AlphaCoef) shr 16);

            end;

            inc(pBits);

          end;

        end;

Ich möchte nur eine Bestätigung das es so ist... Danke.

vorher hatte ich es so.. was aber bedingt durch single(float) um ein 4faches langsamer ist.
bitmap: 4096x4096
elapsed: 2763 bei Verwendung von single.
elapsed: 627 und ULong.

zusammenfalten · markieren

Delphi-Quellcode:

			        for IntI := (bm.bmWidth * bm.bmHeight) downto 1 do

        begin

          if pBits.rgbReserved > 0 then

          begin

            AlphaCoef := (pBits.rgbReserved / 255);

            pBits.rgbBlue := round(pBits.rgbBlue / AlphaCoef);

            pBits.rgbGreen := round(pBits.rgbGreen / AlphaCoef);

            pBits.rgbRed := round(pBits.rgbRed / AlphaCoef);

          end;

          Inc(pBits);

        end;

gruss

**himitsu**

je mehr, um so größer rgbReserved ist, bei beiden Versionen, aber kleiner, bei großem Multiplikator, also ja ... die 2.

Aber warum das "gerundete" Zwischenergebnis und nicht gleich direkt gerechnet?
pBits.rgbBlue := (pBits.rgbBlue * 255) div pBits.rgbReserved;

Wenn es schnell sein soll dan kann man die 3 Werte auch zusammen in einem MMX-Register verrechnen lassen.
Und pssst

markieren

Delphi-Quellcode:

			for allesineinerschleife := 0 to imgH * imgW - 1 do

// oder

for allesineinerschleife := imgH * imgW - 1 downto 0 do // spart noch die interne Ende-Variable, da Ende immer 0

Zitat:

je mehr, um so größer rgbReserved ist, bei beiden Versionen, aber kleiner, bei großem Multiplikator, also ja ... die 2.

Wenn ich dich richtig verstehe die 2. Version mit Shift 16 verwenden.
Die shift 8 könnte also ein Rundungs Problem generieren?

Zitat:

Aber warum das "gerundete" Zwischenergebnis und nicht gleich direkt gerechnet?

auf was beziehst du das bei welchen der 3 Varianten. ?

Danke.

gruss

**himitsu**

AlphaCoef ist ein gerundetes Zwischenergebnis.
Bei 16 ist das natürlich größer und somit die Rundung geringer.
Aber die Rundung ist dennoch bei 8 und 16 drin, nur eben nicht gleich groß.

pBits.rgbBlue := (pBits.rgbBlue * 255) div pBits.rgbReserved; = pBits.rgbBlue := MulDiv(pBits.rgbBlue, 255, pBits.rgbReserved);
aber da deine Werte so klein sind, dass es keinen Überlauf gibt, wäre MulDiv egal (unnötig).

Zitat von himitsu:

AlphaCoef ist ein gerundetes Zwischenergebnis.
Bei 16 ist das natürlich größer und somit die Rundung geringer.
Aber die Rundung ist dennoch bei 8 und 16 drin, nur eben nicht gleich groß.

Ich habe da ein Beispiel in C von einem Forum wo ich gerade arbeite. (englisch nicht so mein Ding)

Da wird mir gesagt! Das rundungs Probleme auftreten auf der Basis dieser Berechnung.

Zitat:

it will be on some values...
for example alpha=250, color=251... then instead of 0 you will get 255,
same with 251:252, 252:253, 253:254, 254:255, ...
if use shift by 16, then there is no this problem

Shift 16 soll das Problem beheben mag ja in C++ zutreffend sein aber unter Delphi ?
Auf Grund dieser Berechnung.

markieren

Code:

			      int err = 0;

      for (ULONG a = 0; a < 256; a++)

      {

         float rAlphaCoef = (float)((float)a / 255.0f);

         ULONG uAlphaCoef = a ? ((255 << 8) / a) : 0;

         for (ULONG c = 0; c < 256; c++)

         {

            BYTE n = (BYTE)(int)((float)c / rAlphaCoef);

            BYTE m = (BYTE)(((ULONG)c * uAlphaCoef) >> 8);

            if (n != m && abs(n - m) > 1)

               wprintf(L"error: a: %03d; c: %03d [n: %05d, m: %05d] %i\n", a, c, n, m, ++err);

         }

      }

Ich bin da jetzt etwas unsicher da ich ihm gesagt habe das ich mit Shift 8 eigentlich keine Sichtbaren unterschiede sehe da mein Icon die Transparenz hat die es haben soll.
Deshalb der Post.

gruss

**Michael II**

Hallo A.Weiss

deine Funktion "Berechne Farbwert'" hängt ja von 2 Parametern Alpha und Farbwert ab.

Wenn die Werte von Alpha und Farbwert in [0..255] liegen, dann schreib doch rasch eine Routine

for Alpha := 0 to 255 do
for FarbWert := 0 to 255 do...

und berechne Farbwert' einerseits nach deiner alten "float basierten Version" und andererseits nach deinen beiden neuen "int Versionen" und vergleiche die Resultate.

Dann weisst du ganz genau was Sache ist.

Zitat von Michael II:

Hallo A.Weiss

deine Funktion "Berechne Farbwert'" hängt ja von 2 Parametern Alpha und Farbwert ab.

Wenn die Werte von Alpha und Farbwert in [0..255] liegen, dann schreib doch rasch eine Routine

for Alpha := 0 to 255 do
for FarbWert := 0 to 255 do...

und berechne Farbwert' einerseits nach deiner alten "float basierten Version" und andererseits nach deinen beiden neuen "int Versionen" und vergleiche die Resultate.

Dann weisst du ganz genau was Sache ist.

Danke das habe ich ja gemacht.

bitmap: 4096x4096
elapsed: 2763 bei Verwendung von single.
elapsed: 627 und ULong.

es geht mir darum ob nun eine Rundungsfehler auftreten kann oder nicht..
Ich konnte keinen ausmachen aber es wird mir so im C++ Forum berichtet

Nun wem oder was soll man nun glauben.

Also unter C++ soll er auftreten und in Delphi nach meinen Tests aber nicht.
Was stimmt denn nun.

gruss

**himitsu**

Och, so viel ist das auch nicht, da kann man docg problemlos alle Varianten vorberechnen und dann nur noch aus der Liste picken.

zusammenfalten · markieren

Delphi-Quellcode:

			type

  PColorArray = ^TColorArray;

  TColorArray = array[0..255] of Integer;

  TAlphaArray = array[0..255] of TColorArray;

var

  AlphaArray: TAlphaArray;

  ColorArray: PColorArray;

for IntI := (bm.bmWidth * bm.bmHeight) - 1 downto 0 do begin

  if pBits.rgbReserved <> 0 then begin

    ColorArray     := @AlphaArray[pBits.rgbReserved]

    pBits.rgbBlue  := ColorArray[pBits.rgbBlue];

    pBits.rgbGreen := ColorArray[pBits.rgbGreen];

    pBits.rgbRed   := ColorArray[pBits.rgbRed];

  end;

  Inc(pBits);

end;

Wie das vorberechnet wird, ist dann egal. (Float, Int8 oder Int16)

Zitat:

Danke das habe ich ja gemacht.

Nee?

Einmal alle Werte mit deiner Variante berechnen, dann nochmal mit 8 und/oder 16
und sie nebeneinander stellen.

zusammenfalten · markieren

Delphi-Quellcode:

			for rgbReserved := 0 to 255 do

  for rgbBlue := 0 to 255 do

  begin

    AlphaCoef1 := 255 div rgbReserved;  // auch mal zum Spaß die extemen Rundungsfehler 

    rgbBlue1 := (rgbBlue * AlphaCoef1);

    AlphaCoef8 := (255 shl 8) div rgbReserved;

    rgbBlue8 := ((rgbBlue * AlphaCoef8) shr 8);

    AlphaCoef16 := (255 shl 16) div rgbReserved;

    rgbBlue16 := ((rgbBlue * AlphaCoef16) shr 16);

    AlphaCoefF := (rgbReserved / 255);

    rgbBlueF := Trunc(rgbBlue / AlphaCoefF);  // Trunc statt Round, damit es vergleichbar ist, da DIV/SHR auch abrundet

  //rgbBlueF := Trunc(rgbBlue / (rgbReserved / 255));  // frei nach den mathematischen Regeln auflösen

  //rgbBlueF := Trunc(rgbBlue / rgbReserved * 255);

  //rgbBlueF := Trunc(rgbBlue * 255 / rgbReserved);

    rgbBlueD := (rgbBlue * 255) div rgbReserved;

    AddToMemo(rgbReserved, rgbBlue, rgbBlue1, rgbBlue8, rgbBlue16, rgbBlueF, rgbBlueD);

  end;

**Michael II**

Zitat:

es geht mir darum ob nun eine Rundungsfehler auftreten kann oder nicht..

Wir verstehen einander nicht. Mir geht's ja auch genau um die möglichen Rundungsfehler.

Du kannst leicht testen, ob Rundungsfehler auftreten, indem du einfach alle möglichen Resultate für alle drei Varianten ausrechnest.

Noch einmal: Da dein Alpha Werte in [0..255] und deine Farbwerte Werte in [0..255] annehmen können, musst du pro Variante genau 256x256 Resultate berechnen (und diese miteinander vergleichen) und weisst danach ganz genau, ob Rundungsfehler auftreten oder nicht. Grund: Du hast dann alle Fälle, welche auftreten können berücksichtigt.

Zitat von Michael II:

Zitat:

es geht mir darum ob nun eine Rundungsfehler auftreten kann oder nicht..

Wir verstehen einander nicht. Mir geht's ja auch genau um die möglichen Rundungsfehler.

Du kannst leicht testen, ob Rundungsfehler auftreten, indem du einfach alle möglichen Resultate für alle drei Varianten ausrechnest.

Noch einmal: Da dein Alpha Werte in [0..255] und deine Farbwerte Werte in [0..255] annehmen können, musst du pro Variante genau 256x256 Resultate berechnen (und diese miteinander vergleichen) und weisst danach ganz genau, ob Rundungsfehler auftreten oder nicht. Grund: Du hast dann alle Fälle, welche auftreten können berücksichtigt.

Ach so

Ja das könnte ich machen.

@himitsu
Danke für die Beispiele.

gruss