Ultragenauer Mandelbrot-Renderer [Archiv]

Ridcully

2003-01-13, 21:21:23

Wenn ich Salvee richtig verstehe ist es möglich die funktionen die zum erzeugen einer fraktalen form wie zb. der Julia Menge mittels eines shaderprograms zu erzeugen.

Nun meine Frage : Wäre es dann nicht relativ (ich könnte es nicht weil ich überhaupt keine ahnung davon habe) einfach möglich so eien Juliamenge dreidimensional darzustellen? Mann mösste doch nur die Farbwerte in höhenwerte umwandel. Das ergebniss mösste eine Art gebirge sein. Und zwar eines das giganisch groß ist. Wäre es sehr schwer so etwas als 3danwendung unzusetzen? Gibt es das schon?

Ridcully

PS Ein Programm mit höherer genauigkeit wäre aber auch nicht schlecht. Aths hat recht: die genauigkeit läßt einen immer dan im stich wenn man was interessantes gefunden hat.

aths

2003-01-13, 21:35:17

Ridcully,

ob nun Farb- oder Höhenwerte... im Prinzip sind es schon Höhenwerte, die man berechnet, dann aber in "Draufsicht" mit Farben darstellt. Und ja, es gibt bereits Programme die sowas visualisieren. Xaos z.B. Ist aber reines Software-Rendering.

aths

2003-01-13, 21:36:37

Originally posted by Desti
http://www.jimbomania.com/david/index.html

http://www.cs.helsinki.fi/u/salerma/gfract/

Sonst schau mal auf sourceforge.net und freshmeat.net, da gibts noch mehr Ich habe kein Linux installiert.

aths

2003-01-13, 21:38:19

Originally posted by Salvee
Auf ZDNet gibt es scheinbar 22 verschiedene Generatoren, allerdings bar jeglicher Beschreibung bezüglich Präzision.

http://downloads-zdnet.com.com/3120-20-0.html?qt=mandelbrot&tg=dl-2001 Einige kenne ich schon, scheinen alle Standard Datentypen (also maximal 64 Bit) zu verwenden.

StefanV

2003-01-13, 21:53:40

Originally posted by aths
Einige kenne ich schon, scheinen alle Standard Datentypen (also maximal 64 Bit) zu verwenden.

Daß die FPU 'normalerweise' 'nur' 80bit Präzise ist, weißt du aber, oder ??

Es könnte ja sein, daß es ein Problem mit der Präzision der Hardware gibt...

aths

2003-01-13, 22:27:03

Originally posted by Stefan Payne

Daß die FPU 'normalerweise' 'nur' 80bit Präzise ist, weißt du aber, oder ??

Es könnte ja sein, daß es ein Problem mit der Präzision der Hardware gibt...
Originally posted by aths
Ich suche einen ultra genauen Mandelbrot-Renderer für Deep Zooms ins Apfelmännchen. 64 Bit FP reicht für meine Bedürfnisse nicht mehr aus :) Gibts da nicht was, was 128 Bit FP "emuliert"?

Frank

2003-01-13, 22:30:00

Originally posted by Stefan Payne

Daß die FPU 'normalerweise' 'nur' 80bit Präzise ist, weißt du aber, oder ??

Es könnte ja sein, daß es ein Problem mit der Präzision der Hardware gibt...
Das hat aber nichts mit der Genauigkeit zu tun, in der man sowas programmieren kann. Nimm zb ein Fortrancompiler und der bietet die auch mehr als 80bit floats oder was auch immer. Das der Rechner da in die Knie geht is klar - dafür reicht schon ein nettes Newtonverfahren (simple Schulstoff) um einen P4 ordentlich rechnen zu lassen :D

Unregistered

2003-01-13, 23:03:26

Originally posted by X-Dragon
Sowas vieleicht?
http://members.optusnet.com.au/~peterstone/escp.html

sonst schau mal dort:
http://www.google.de/search?hl=de&lr=&ie=UTF-8&oe=UTF-8&q=mandelbrot+%22128+bit%22+floating+point&spell=1 :)

das war kein SPAM ... sondern ne normale Frage !
aber gut, musst ja nicht antworten wenn du dir zu fein bist ;) :)

gruß
El_Mariachi

Unregistered

2003-01-13, 23:04:50

auch noch das falsche post gequotet .. sorry X-Dragon

sollte das von Aths werden :)

El_Mariachi

zeckensack

2003-01-16, 08:07:07

aths,

Gibt es einen OpenSource-Generator, der dir von der Bedienung her zusagt?

Vielleicht kann man da was drehen :)

aths

2003-01-16, 12:00:43

Originally posted by zeckensack
aths,

Gibt es einen OpenSource-Generator, der dir von der Bedienung her zusagt?

Vielleicht kann man da was drehen :) Wäre so ein OpenSource-Generator auch unter Windows zum Laufen zu kriegen? Wenn du ansonsten nach fertigen offenen Quellen fragst, hm, Xaos ist imo kein Open Source, bei Fractint hingegen gibts auch den Quelltext, nur ist der sicherlich schon so hoch optimiert, dass man da nicht mal eben mit Search&Replace groß was machen kann.

RadioactiveMan

2003-01-16, 20:01:07

@aths

klar, gerade Cygwin http://www.cygwin.com/ wurde entwickelt damit auch Unix-Programme schnell und einfach auf win32 portiert werden können.

Xaos ist übrigens auch OpenSource und kann mit Cygwin übersetzt werden.
http://sourceforge.net/projects/xaos/

Für die von dir geforderte Präzision würde ich Mathematikpakete wie Mathematica oder Maple nehmen, da deren Kernel auf Präzision optimiert wurden.
Mathworld(ne super Matheseite) bietet etwa Mathematica Sourcecode für derartige Fraktale auch schon an. (in den Mathematica Notebooks enthalten)

http://mathworld.wolfram.com/MandelbrotSet.html
http://mathworld.wolfram.com/JuliaSet.html

zeckensack

2003-01-16, 20:03:06

Originally posted by aths
Wäre so ein OpenSource-Generator auch unter Windows zum Laufen zu kriegen? Wenn du ansonsten nach fertigen offenen Quellen fragst, hm, Xaos ist imo kein Open Source, bei Fractint hingegen gibts auch den Quelltext, nur ist der sicherlich schon so hoch optimiert, dass man da nicht mal eben mit Search&Replace groß was machen kann. Ich frage vor allem deswegen, weil das User-Interface an so einem Generator das schwierigste ist.

Und gleichzeitig ist es das, was ich am wenigsten gut kann ... :D

Der Mandelbrot-Algo selbst ist ja nicht mal ein dutzend Zeilen lang (in C). Man müßte dort 'nur' den Datentyp float durch einen eigenen, präziseren ersetzen (am besten eine C++ -Klasse). Mir schweben so mindestens 128 Bit für die Mantisse vor :D

Wuzel

2003-01-16, 20:37:02

Originally posted by zeckensack
Ich frage vor allem deswegen, weil das User-Interface an so einem Generator das schwierigste ist.

Und gleichzeitig ist es das, was ich am wenigsten gut kann ... :D

Der Mandelbrot-Algo selbst ist ja nicht mal ein dutzend Zeilen lang (in C). Man müßte dort 'nur' den Datentyp float durch einen eigenen, präziseren ersetzen (am besten eine C++ -Klasse). Mir schweben so mindestens 128 Bit für die Mantisse vor :D

Bisst du da sicher ?
Also, wenn du einen Ago für das Problem ( ich habe null Plan von dem Mandel Zeug ) schreibst, der eine so hohe genauigkeit hat ... Dann mach ich das Gui -> no prob.

aths

2003-01-17, 03:04:47

Also, folgendes muss das Ding können damit es Sinn macht:

- Direkte grafische Ausgabe.

- Support von "Verschnellerungs"-Methoden: Pixelweise Berechnung
dauert zu lange. Man kann das mit Boundary Tracing beschleunigen. Einfachere Methode: Rendern von Rahmen. Haben die die gleiche Pixelfarbe am Rand, kann der Kasten mit einem Schlag ausgefüllt werden. (Beides erzeugt keine falschen Bilder.)

- Neuvergrößerung durch Rahmen. Neue Zahlen einzugeben ist zu unhandlich.

- Support von Paletten mit 256 Farben.

- Anti-Aliasing. (z.B. 5x, erst die Mittel-Subpixel rendern und dann die anderen Subpixel per "T-Buffer".)

- Support von Julia-Sets. (Minimale Änderung der Formel.)

Nett wäre die Möglichkeit, das Programm kontrolliert abzubrechen. Also in mehreren Sitzungen zu rendern.

(Ebenso wäre ein Julia-Realtime-Evolver nett. Darunter verstehe ich ein Performance-optimierten Julia-Renderer, und man kann in Echtzeit die die Parameter ändern. Sollte dann 32 Bit Integer fixed Point aber auch 64 Bit Floating Point unterstützen.)

Wuzel

2003-01-17, 07:27:28

Hmmm,

Also dann bräuchten wir im einzelnen meiner Meinung nach :

-> Engine zum berechnen
-> Rendering Engine
-> Gui

Das ganze , so wie sich's für mich anhört Multithreaded ;)

Ich könnte machen ( aus fun weil mich sachen reizen dies nich gibt ) :

-> Gui ( MFC 7 )
-> Threading
-> Interface ( z.b Com ums Modular und die einzelnen Teile Plattformunabhängig zu kriegen ).
-> ev. ATL ( DCOM ) Unterstüzung für entferntes/verteiltes berechnen

Mann das wär doch lustig, bestimmt auch nen guter protzbenchmark :D

aths

2003-01-17, 10:22:54

Wuzel,

die Mathematik dahinter ist eigentlich höchst einfach. Bestimmung des Pixel-Farbwertes:

1. Umrechnung Pixel-Position in 2D-Koordinate (Die Mandelbrot-Menge befindet sich in einem Kreis um den Koordinatenursprung mit dem Radius 2)

2. Verwendung dieser Koordinaten als Parameter für die Berechnung

3. Diese Berechnung wiederholt sich so lange, bis das Ergebnis entweder 4 erreicht oder übersteigt, oder eine gewisse Anzahl an Zyklen durchgeführt wurde.

4. Man zählt die Zyklen mit. Sie bestimmen welcher Paletteneintrag gewählt wird. Musste wegen Überschreitung der Interationsgrenze abgebrochen werden, wird eine Spezialfarbe (in der Regel schwarz) verwendet.

Zecki sollte das System kennen :)

Wichtig wäre wie gesagt der Support von "Abkürzungen", um - wenn möglich - ganze Blöcke mit einem Schlag ausfüllen zu können, sowie eine Verwaltung mehrer Buffer fürs Anti-Aliasing.

Zum Bild, was sich ergibt: Der Trick liegt in der Rückkopplung. Die Koordinaten als Eingabe-Parameter werden in jedem Zyklus verfremdet und für den nächsten Zyklus verwendet. Dadurch entstehen chaotische Strukturen (die aber determiniert sind, da ja ohne Zufallszahlen gerechnet wird.)

zeckensack

2003-01-17, 12:23:23

Jupp.

Ich hab' gerade eine Minimal-Implementierung in C++ zusammengehauen, nur zur Demonstration des Algos:
#include <stdio.h>
#include <stdlib.h>

typedef unsigned char ubyte;

class
ComplexNumber
{
public:
ComplexNumber():r(0.0),i(0.0) {};
ComplexNumber(double r,double i):r(r),i(i) {};
double r;
double i;

void square() {
double tmp=r;
r=r*r-i*i;
i=2*i*tmp; }
operator += (const ComplexNumber& rhs) {
r+=rhs.r;
i+=rhs.i; }
};

int
main()
{
ubyte* gnarf=(ubyte*)malloc(512*384*sizeof(ubyte));

ComplexNumber c;
ComplexNumber z;
for (int x=0;x<512;++x) for (int y=0;y<384;++y)
{
c.r=-0.5+x*1.0/512u;
c.i=0.5+y*1.0/384u;
z.r=0.0;
z.i=0.0;

int it=0;
do
{
++it;
z.square();
z+=c;
} while (((z.i*z.i+z.r*z.r)<4.0)&&(it<1024));
if (it==1024) gnarf[512*y+x]=0;
else gnarf[512*y+x]=ubyte(255-(it%255));
}

FILE* wuss=fopen("wuss","wb");
fwrite(gnarf,512,384,wuss);
fclose(wuss);
free(gnarf);

return(0);
}

So, das ist wirklich nichts dolles, kein User-Interface, keine Parameter und grottenlahm. Das ist der 'klassische' Algorithmus ohne jede Optimierung. Auch wird nur ein Ausschnitt erzeugt, die Mandelbrotmenge ist definiert zwischen -2 und +2, jeweils in z.r und z.i (siehe rot markierten Code).

Die Datei, die dabei herauskommt, kann man zB in Paintshop Pro als RAW laden. Das sind nur Graustufen, Ziel der Übung sollte das Einfärben mit einer möglichst kontrastreichen Palette sein.

Jedenfalls sieht das schonmal so aus

aths

2003-01-17, 16:11:54

Ausgezeichnet :))

zeckensack

2003-01-17, 16:41:57

aths,

kannst du mal einen ungefähren Koordinatenauschnitt angeben, bei dem die Präzision bei deinen Generatoren nicht mehr ausreicht?

Ich würde gerne ein präziseres Fließkommaformat implementieren, bräuchte aber zum Testen einen Fall, wo man auch tatsächlich etwas sinnvolles sieht :)

Ridcully

2003-01-17, 17:33:14

wow das 3dcenter forum begeistert mich immer wieder! Nicht nur schwätzen sondern auch tun. Klasse. Leider kann ich euch überhaupt nicht helfen da ich kein bischen Programmieren kann (oder soll ich das Programm in Java Script schreiben? ).

Als einzigen hilfe kann ich euch anbieten virtuellen kaffe zu kochen und brötchen zu holen ;-).

Ridcully *kaffeundbrötchenholengeht*

Wuzel

2003-01-17, 18:09:03

Originally posted by zeckensack
Jupp.

Ich hab' gerade eine Minimal-Implementierung in C++ zusammengehauen, nur zur Demonstration des Algos:

....

So, das ist wirklich nichts dolles, kein User-Interface, keine Parameter und grottenlahm. Das ist der 'klassische' Algorithmus ohne jede Optimierung. Auch wird nur ein Ausschnitt erzeugt, die Mandelbrotmenge ist definiert zwischen -2 und +2, jeweils in z.r und z.i (siehe rot markierten Code).

Die Datei, die dabei herauskommt, kann man zB in Paintshop Pro als RAW laden. Das sind nur Graustufen, Ziel der Übung sollte das Einfärben mit einer möglichst kontrastreichen Palette sein.

Jedenfalls sieht das schonmal so aus

Hmmm, ich schau mir das mal genauer an und bau nen SDI drum rum ( mit Dokumenten wo das reingepustet wird -> sollte funzen ).
Sobald ich Zeit hab mach ich das schnell, spätestens Sonntag/Abend fertich.

Sooo wild iss das ja garnich :D

Wuzel

2003-01-17, 18:36:33

Hmmmmmmmmmmmm.

Irgendwie Lustich :D

aths

2003-01-17, 18:42:56

Originally posted by zeckensack
Ich würde gerne ein präziseres Fließkommaformat implementieren, bräuchte aber zum Testen einen Fall, wo man auch tatsächlich etwas sinnvolles sieht :) (maxiter 2000000)

(view -1.2840491481212999339E 0.42738332950945581690 1.658829323902821784E-17 1.6344347750218979343E-17)

Das blöde Xaos speichert leide von-bis-Koordinaten sondern nur die Mitte und Zusatz-Informationen. Ich nehme an, die ersten beiden Zahlen sind X und Y jeweils mittig, und die anderen beiden geben die Größe des Ausschnitts an.

zeckensack

2003-01-17, 19:13:43

Hrhrhr.

Ich bin gerade bei der Fließkomma-Klasse. Mal so zum Vergleich:
floats sind s8e23m (Vorzeichen, 8 Bits Exponent, 23 Bits Mantisse)
doubles sind s10e53m

Und die Klasse wird s32e191m sein *eg*

Ich hoffe noch heute meine ersten Multiplikationserlebnisse zu haben :naughty:

zeckensack

2003-01-17, 20:03:41

Ui, das wird lahm =)

Eine Multiplikation zweier ExtremeFloats ( :stareup: ) besteht aus 80 Zeilen Assembler, benötigt unter anderem 36 Integer-Multiplikationen und hat eine 50/50-Chance, weitere 6 Bit-Shifts zu brauchen :lol:

nggalai

2003-01-17, 20:09:29

Originally posted by zeckensack
Hrhrhr.

Ich bin gerade bei der Fließkomma-Klasse. Mal so zum Vergleich:
floats sind s8e23m (Vorzeichen, 8 Bits Exponent, 23 Bits Mantisse)
doubles sind s10e53m

Und die Klasse wird s32e191m sein *eg*

Ich hoffe noch heute meine ersten Multiplikationserlebnisse zu haben :naughty: LOL !!!

Jungs, ich glaube ihr baut hier auch gleich einen interessanten Benchmark. Und als CPU-Belastungs-Test ist der sicher auch noch gut zu gebrauchen. *eg*

ta,
-Sascha.rb

Wuzel

2003-01-17, 21:29:50

Originally posted by zeckensack
Ui, das wird lahm =)

Eine Multiplikation zweier ExtremeFloats ( :stareup: ) besteht aus 80 Zeilen Assembler, benötigt unter anderem 36 Integer-Multiplikationen und hat eine 50/50-Chance, weitere 6 Bit-Shifts zu brauchen :lol:

Frage :
Als was kommt das zurück ???
Ich meine, am geschicktesten wäre ein mehrdimensionales Array als Rückgabewert.
Und zwar 'Zeilenweise' , dann könnt ich theoretisch einfach nur die einzelnen Points printen und so fürs 'Rohformat' ein BMP erzeugen.
Damit kann man dann alles machen.
Ist alerdings dann lahm, schätze ich mal.
Also [int zeile][int pixel][int pixelWert] -> was für einen wert dann der Pixel hätte wäre Wurscht, sagen wir mal zwischen 1-10 -> ich bau dann eine Option wo die einzelen Farben für die Stufen Auswählbar wären ( 1 ist z.B intensiv, 10 schwach , der user könnte für '1' rot und für '10' gelb nehmen usw. )

Irgendwie so in der Art halt, brauche irgend ein 'Raster' was ich abfragen könnte.

zeckensack

2003-01-17, 22:11:23

Originally posted by Wuzel

Frage :
Als was kommt das zurück ???
Ich meine, am geschicktesten wäre ein mehrdimensionales Array als Rückgabewert.
Und zwar 'Zeilenweise' , dann könnt ich theoretisch einfach nur die einzelnen Points printen und so fürs 'Rohformat' ein BMP erzeugen.
Damit kann man dann alles machen.
Ist alerdings dann lahm, schätze ich mal.
Also [int zeile][int pixel][int pixelWert] -> was für einen wert dann der Pixel hätte wäre Wurscht, sagen wir mal zwischen 1-10 -> ich bau dann eine Option wo die einzelen Farben für die Stufen Auswählbar wären ( 1 ist z.B intensiv, 10 schwach , der user könnte für '1' rot und für '10' gelb nehmen usw. )

Irgendwie so in der Art halt, brauche irgend ein 'Raster' was ich abfragen könnte. Das funktioniert so, daß der Benutzer erst mal ein paar Werte eingeben muß, und zwar (siehe aths) einen 2D-Startpunkt und eine 2D-Ausdehnung. Dieser Wertebereich wird dann mit dem Algo durchgerattert, es werden pro Pixel die Iterationen gezählt, bis das Ding terminiert.
Das Ergebnis ist dann also ein 2D-Array von Integern (<- Bytes reichen).

Schlauerweise sollte die steurnde App dieses Array verwalten, denn sie erzeugt ja auch das Fenster wo das ganze reinpassen soll.

Dem Mandelbrot-Generator muß neben den Koordinateneingaben des Users die Auflösung des Zielbilds bekannt sein (dadurch bestimmt sich die Schrittweite zwischen den Pixeln).

Also mal der Prototyp um das Ding anzuwerfen, sähe ungefähr so aus:

void brot_backen(unsigned char* result_array,int result_width,int result_height,double param_x,double param_y,double param_width,double param_height);

Die dicken Teile sind die die Koordinaten für die Funktion, nicht für's Display. Für die braucht man dann eigentlich auch schon präzisere Datentypen.

Apropos ... im Moment ist bei mir noch

17 + 12 = 16
17 * 12 = 128

und ähnlicher Unsinn ... ?-)

aths

2003-01-18, 12:17:52

*Schüchtern den Finger heb*

Es wäre vielleicht nicht schlecht, gleich Oversampling-Support zu haben. D.h., dass die Ausgabe um einen ganzzahligen Faktor auf beiden Achsen verkleinert wird.

Angenommen man möchte 1024x768 mit 3x3 Oversampling haben, dann muss ein 3072x2304-Bild zurück geliefert werden.

Datenformat: Ein Byte pro Pixel würde ausreichen (Farbe aus einer 8-Bit-Palette.) Die Anzeige-Engine müsste also zunächst aus dem Byte und der Palette den RGB-Wert ermitteln, und dann je nach AA-Modus einen Block von 2x2, 3x3 oder 4x4 in einen einzelnen RGB-Wert zusammen fassen, welcher dann ausgegeben wird.

Aus berechnungstheoretischen Gründen sind übrigens nur 255 Farben verwendbar, da man eine "Farbe" für die Information "Pixel wurde noch nich berechnet" braucht.

Wuzel

2003-01-18, 13:09:24

Originally posted by zeckensack
Das funktioniert so, daß der Benutzer erst mal ein paar Werte eingeben muß, und zwar (siehe aths) einen 2D-Startpunkt und eine 2D-Ausdehnung. Dieser Wertebereich wird dann mit dem Algo durchgerattert, es werden pro Pixel die Iterationen gezählt, bis das Ding terminiert.
Das Ergebnis ist dann also ein 2D-Array von Integern (<- Bytes reichen).

Schlauerweise sollte die steurnde App dieses Array verwalten, denn sie erzeugt ja auch das Fenster wo das ganze reinpassen soll.

Dem Mandelbrot-Generator muß neben den Koordinateneingaben des Users die Auflösung des Zielbilds bekannt sein (dadurch bestimmt sich die Schrittweite zwischen den Pixeln).

Also mal der Prototyp um das Ding anzuwerfen, sähe ungefähr so aus:

void brot_backen(unsigned char* result_array,int result_width,int result_height,double param_x,double param_y,double param_width,double param_height);

Die dicken Teile sind die die Koordinaten für die Funktion, nicht für's Display. Für die braucht man dann eigentlich auch schon präzisere Datentypen.

Apropos ... im Moment ist bei mir noch

17 + 12 = 16
17 * 12 = 128

und ähnlicher Unsinn ... ?-)

Ahh jetzt hats geklingelt.

Dann hät ich zwei möglichkeiten, einmal über die 'normalen' Bitmapfunktionen , ich nehm das Array und Füll damit ein bitmap ab -> Speicherintensiv.
Oder halt über directDraw, Rect nehmen und das Array neiklatschen.
Hmm, das müsste man alles mal durchtesten, DirectDraw hätte aber hier gewisse Vorteile.

Mir schwants schon, viiieelll zu tun ;)

Wuzel

2003-01-18, 13:13:06

Originally posted by aths
*Schüchtern den Finger heb*

Es wäre vielleicht nicht schlecht, gleich Oversampling-Support zu haben. D.h., dass die Ausgabe um einen ganzzahligen Faktor auf beiden Achsen verkleinert wird.

Angenommen man möchte 1024x768 mit 3x3 Oversampling haben, dann muss ein 3072x2304-Bild zurück geliefert werden.

Datenformat: Ein Byte pro Pixel würde ausreichen (Farbe aus einer 8-Bit-Palette.) Die Anzeige-Engine müsste also zunächst aus dem Byte und der Palette den RGB-Wert ermitteln, und dann je nach AA-Modus einen Block von 2x2, 3x3 oder 4x4 in einen einzelnen RGB-Wert zusammen fassen, welcher dann ausgegeben wird.

Aus berechnungstheoretischen Gründen sind übrigens nur 255 Farben verwendbar, da man eine "Farbe" für die Information "Pixel wurde noch nich berechnet" braucht.

Für diesen Fall würde ich um DirectDraw nicht rumkommen, hau die 3072x2304 in den backbuffer und 'resize' das ganze direkt auf der Kraka runter zu 1024x768 -> das wird dann released.
Ohh Jummi, *megaengineschreibenmuss*

aths

2003-01-18, 14:03:55

Originally posted by Wuzel
Für diesen Fall würde ich um DirectDraw nicht rumkommen, hau die 3072x2304 in den backbuffer und 'resize' das ganze direkt auf der Kraka runter zu 1024x768 -> das wird dann released.
Ohh Jummi, *megaengineschreibenmuss* Dumm frag: Sind solch großen Backbuffer mit DirectDraw möglich? Ich weiß nicht, wie die Graka downfiltert. Das per SW zu machen ist sicher langsam, aber nicht schwer zu implementieren.

Hier stünde noch die Idee des allmählichen Grafikaufbaus. Also dass man nicht nur das fertige Frame sieht, sondern es (einstellbar) in gewissen Zeitabständen refresht wird. Dazu müsste jedesmal downgefiltert werden, aber Geschwindigkeitsrekorde bricht dieser Renderer ohnehin nicht.

aths

2003-01-18, 14:11:07

Beschleunigung des Rechenvorganges:

Die beste Möglichkeit ist, das Bild in 2 Hälften zu teilen. Es wird um jede Hälfte der Rahmen berechnet. Hat er überall die gleiche Farbe, wird er (sozusagen mit Blockfill) schlagartig eingefärbt. Ansonsten wird die Hälfte wieder neu in 2 Hälften geteilt (die Teilung muss abwechselnd vertikal und horizontal erfolgen) und die Rahmen werden erneut geprüft...

Es ginge auch "billiger". Dazu wird das Bild in feste Blöcke unterteilt, und diese dann vielleicht noch mal in feste Unterblöcke. Ziel dieser Maßnahmen ist, im "Kern" so wenig Pixel wie möglich berechnen zu müssen, da man bei Deep Zooms schon mal Iterationsgrenzen von mehreren Millionen braucht. Und das bei ultragenauer Rechnung würde seeehr lange dauern :)

Wenn mal mitten im Bild 'n kleines Apfelmännchen ist, spart man wenig. Zoomt man aber nahe an den Körper, so dass sich viel Schwarz im Bild einfach nicht vermeiden lässt, sind solche Methoden unbedingt notwenig.

Es gibt auch Möglichkeiten, wenn man in einer Reihe schwarze Pixel berechnet, das zu beschleunigen. Irgendwie lässt sich "erahnen", dass die nächsten Pixel auch schwarz sind so dass man temporär die Iterationsgrenze senken kann. Wie das genau funktioniert weiß ich aber nicht. Ohnehin spart man am meisten ein, wenn ganze Blöcke schlagartig gefüllt werden.

Die Blöcke böten auch die Möglichkeit eines schnellen Vorschau-Bildes.

zeckensack

2003-01-18, 14:12:36

Originally posted by aths
Geschwindigkeitsrekorde bricht dieser Renderer ohnehin nicht. Das ist mein Stichwort.

Davon abgesehen, daß ich die dringend benötigte Subtraktion noch nicht implementiert habe, brauchen wir ganz dringend ein paar funktionierende Optimierungen.

Es wäre wirklich am leichtesten, wenn man einen bestehenden Mandelbrot-Bäcker einfach nur um das bessere Datenformat erweitern könnte. Aber Xaos und Fractint sind ... hmmm ... bis zum Erbrechen kaputt-optimiert :|

Die haben da Sachen gemacht, schämen sollten die sich.
Verstehen tue ich da bisher nichts. Ich habe vor lauter Makros und wüstem Gewusel nicht mal die eigentliche Generierungs-Funtkion gefunden ?-)

aths

2003-01-18, 14:39:46

Xaos ist als Realtime-Renderer ohnehin speziell optimiert. Und Fractint startete afaik als reine Integer-basierte Engine. (Lange Zeit gabs z.B. eine Iterationsgrenze von 32767, das war für einen AT 286-er vielleicht noch ok...) Zur Beschleunigung siehe ein Posting über dir :)

Ganon

2003-01-18, 15:01:22

Hi,

ich will jetzt nicht stören, aber ich hätte ein paar Fragen:

1. Was ist das, worüber ihr hier redet?

2. Ich hab mir mal XaoS runtergeladen und mal ausprobiert! Wozu braucht man so ein "Bild" denn? Nur zum angucken, oder wie? Sieht nämlich so aus als wenn einer auf Drogen wäre!:D;)

3. Was bringen einem die 128bit denn, von dem ihr redet? Um noch tiefer in die "Figur" reinzoomen zu können, oder was?

Diese Fragen sind nicht blöd gemeint! Ich würde es nur mal gerne wissen wollen, denn es scheint den Prozi ja richtig zu stressen!

aths

2003-01-18, 15:04:39

Originally posted by Ganon
1. Was ist das, worüber ihr hier redet?Über das bekannteste Fraktal. Frakale sind mathematisch erzeugte Gebilde mit besonderen Eigenschaften. (Unter anderem Selbstähnlichkeit, nicht ganzzahligen Dimensionen u.a.)
Originally posted by Ganon
2. Ich hab mir mal XaoS runtergeladen und mal ausprobiert! Wozu braucht man so ein "Bild" denn? Nur zum angucken, oder wie? Sieht nämlich so aus als wenn einer auf Drogen wäre!:D;)Was du da siehst, enthält die komplizierteste Struktur die überhaupt bekannt ist. Witzigerweise mit einer sehr einfachen Formel erzeugt.
Originally posted by Ganon
3. Was bringen einem die 128bit denn, von dem ihr redet? Um noch tiefer in die "Figur" reinzoomen zu können, oder was?Wenn du mit Xaos genügend tief zoomst, wird das Bild irgendwann "grob". Statt Pixel gibts komische Flecken, oder andere Artefakte. Das liegt an der begrenzten Auflösung des Zahlensystems der Maschine. Erhöht man die Auflösung, kann man tiefer zoomen. (Mit Xaos kommst du Defaultmäßig erst mal an die Iterations-Grenze. Wenn im Bild die schwarzen Fläche keinen "fraktalen" Rand mehr zeigt, muss man die Iterationsgrenze im Menü ("Calculation") erhöhen. (Z.B. eine Null anhängen.)

In Xaos siehst du zunächst das "Apfelmännchen" im Überblick. Zoome mal vorne in den "Rüssel" rein. Dort wirst du kleinere Apfelmännchen finden. Eines ist aber besonders groß. Gucke dir den Abstand von diesem bis zum Hauptkörper an. Zwei kleinere fallen sofort auf. Zoome nun zwischen Hauptkörper und dem nächst liegendem kleineren Apfelmännchen....

Interessant sind "Verwirbelungen", die du am "Hals" des Hauptkörpers finden kannst. Jedes kleinere Apfelmännchen enthält übrigens ein komplettes Abbild des großen - inkl. seiner kleinen "Brüder". In der nähe der kleinen Dinger gibts also wieder weitere, noch kleinere Apfelmännchen, um diese sind auch wieder nochmals kleinere... das geht bis in das Unendliche.

Über solche "unendlich dünnen Fäden" sind nun auch noch ALLE dieser Dinger miteinander verbunden. Man könnte eine Linie einmal um das gesamte Apfelmännchen ziehen, und dabei würde jedes Unter-Apfelmännchen erfasst werden.

Diese Linie hat eine Länge, die nicht abzählbar unendlich ist. Der Umfang von so genannten Julia-Mengen ist auch unendlich, aber abzählbar unendlich.

Die Mandelbrotmenge stellt eine Karte aller Julia-Mengen dar. Anders herum gibt es für jede Koordinate im Apfelmännchen (= Mandelbrot-Set) ein Julia-Set.

Lustig ist auch, dass sich im Apfelmännchen verschiedene Grund-Strukturen finden lassen. Zoomt man in einen Bereich, wo eine bestimmtes Grund-Aussehen vorherrscht in einen Ausschnitt wo eine andere Struktur sein müsste, findet man diese - wobei sich beide Arten überlagern, was zu interessanten Verfremdungen führen kann.

So schön kann das Chaos sein (Ausschnitt aus der Mandelbrot-Menge)

http://www.aths.net/mbr/gal7.gif

Und hier mal ein paar Julia-Mengen:

http://www.aths.net/mbr/gal6.jpg
http://www.aths.net/mbr/gal8.jpg

Und hier ein paar Sets mit einem 3x3 Evolver:

http://www.aths.net/mbr/gal1.jpg
http://www.aths.net/mbr/gal3.gif

Die eingeblendete URL in den Bildern kannste allerdings vergessen. Von diesem Prog habe ich den Quelltext in Teilen verloren, das heißt das Ding gibts nicht mehr. Das letzte Bild wurde außerdem mit einem Postfilter der in diesem Programm integriert war behandelt.

Julia-Mengen sind weniger komplex und daher hat man kaum das Bedürfnis für Deep Zooms. Ein ultragenauer Mandelbrot-Renderer ist imo erst mal wichtiger als ein Realtime Julia-Evolver.

Wuzel

2003-01-18, 15:59:36

Hui, also beim 'Renderer' muss ich eindeutig passen.
Das Gui, die Schnitstellen , alles kein Thema, hier bin ich nach wie vor dabei ( auch wenns darum geht das Teil in verschiedene Formate wie z.B JPEG etc. auszugeben, wenns mal im Docu ist, ist no prob ).

Der Renderer wird alerdings 'aufwendig' hier braucht man Erfahrung, die mir fehlt. Ein paar daten ins Doc zu pusten und auszugeben geht ja noch, das was da alerdings nötig ist ....

Hab vorhin einfach mal versucht Arrays mit 'Inhalt' die ungefähr dabei rauskommen, auszugeben -> hmmmmmmmm, ist sehr sehr Speicherintensiv :D

Ganon

2003-01-18, 16:18:35

@aths

Danke!

Wieder was dazu gelernt! Scheint alles irgendwie unvorstellbar...! Mein Rechner rattert schon seit 30min. an einem Zoom des Start-Bildes! Mal sehen ob der überhaupt fertig wird!

aths

2003-01-18, 16:22:17

Originally posted by Ganon
@aths

Danke!

Wieder was dazu gelernt! Scheint alles irgendwie unvorstellbar...! Mein Rechner rattert schon seit 30min. an einem Zoom des Start-Bildes! Mal sehen ob der überhaupt fertig wird! Wenn du Xaos "im Hintergrund" rendern lassen willst, solltest du vorher im Taskmanager die Prozess-Priorität von Xaos auf "Niedriger als Normal" setzen. Sonst ist im Vordergrund kaum noch arbeiten möglich.

aths

2003-01-18, 16:23:26

Originally posted by Wuzel
Der Renderer wird alerdings 'aufwendig' hier braucht man Erfahrung, die mir fehlt. Ein paar daten ins Doc zu pusten und auszugeben geht ja noch, das was da alerdings nötig ist ....Wenn ich das richtig verstanden habe, würde sich Zeckensack um diesen Teil kümmern.
Originally posted by Wuzel
Hab vorhin einfach mal versucht Arrays mit 'Inhalt' die ungefähr dabei rauskommen, auszugeben -> hmmmmmmmm, ist sehr sehr Speicherintensiv :D Japp, das Ding aast mit dem Speicher nur so rum.

Was die Einfärbung angeht: Ich suche mal ein paar PAL-Files zusammen.

Ganon

2003-01-18, 17:15:35

Originally posted by aths
Wenn du Xaos "im Hintergrund" rendern lassen willst, solltest du vorher im Taskmanager die Prozess-Priorität von Xaos auf "Niedriger als Normal" setzen. Sonst ist im Vordergrund kaum noch arbeiten möglich.

Hi,

ich habs unter Linux laufen! Wenn da ein Programm mit 96%-Auslastung ankommt macht das nichts! Man kann normal an der Oberfläche weiterarbeiten und sogar nebenbei MP3s hören! Aber für DivX-Videos reichts nicht mehr, da die auch mit 96% antanzen!;)
(Das soll jetzt kein Seitenhieb gegen Windows sein, sondern nur eine Beschreibung wie es bei mir ist! Nicht das sich das Thema wieder ändert!)

Aber ich hab auch schon wieder abgebrochen! Denn meine Kousine ist gerade zu besuch und hat gerade gesehen was ich gemacht hab, da sagte sie gleich:
"Haben wir in der Uni auch mal gemacht! Nach 2 Tagen war er fertig!"

Naja, fand ich nicht gerade motivierend!:D;)

Kann man in Xaos auch irgendwie die Auflösung erhöhen so das das Bild größer wird?

Ist aber schon alles interessant! Nur leider dauert mir das ganze mit nem P3@700 zu lange!:D;)

Wer kommt eigendlich auf solche sachen, bzw. auf solche Formeln die ins Unendliche gehen und dabei solche Bilder ausspucken?

aths

2003-01-18, 17:34:58

Originally posted by Ganon
Kann man in Xaos auch irgendwie die Auflösung erhöhen so das das Bild größer wird?Man kann es von der Konsole aufrufen, oder in X-Windows. Dort kann man bequem das Fenster zoomen.
Originally posted by Ganon
Wer kommt eigendlich auf solche sachen, bzw. auf solche Formeln die ins Unendliche gehen und dabei solche Bilder ausspucken? Die Formel wurde afaik mal zum Benchmarken genutzt, die Entdeckung dass sie eine Struktur erzeugt war iic zufällig. Ein gewisser Benoit Mandelbrot beschäftigte sich dann damit (und mit anderen Fraktalen) und schrieb ein Buch über die fraktale Geometrie der Natur.

aths

2003-01-18, 17:43:27

Originally posted by aths
Was die Einfärbung angeht: Ich suche mal ein paar PAL-Files zusammen. http://www.aths.net/files/paletten.zip

Enthält fortlaufen die Farbwerte R, G, B

Wuzel

2003-01-18, 18:07:31

Originally posted by aths
Wenn ich das richtig verstanden habe, würde sich Zeckensack um diesen Teil kümmern.
Japp, das Ding aast mit dem Speicher nur so rum.

Was die Einfärbung angeht: Ich suche mal ein paar PAL-Files zusammen.

Also ich hab mal rumexperimentiert.
Um ein BMP kommt man nicht rum, daraufolgende bearbeitungen werden sonst nur unötig erschwert ( abspeichern, konvertieren, anzeigen - zoomen etc. ).
Der Renderer sollte also im Heap nen BMP ablegen und mir die 'Adresse' mitteilen.
Ich geb quasi dem Konstruktur oder Vari. Initialisierenden Funktion die Auflösung ( und das andere Zeuch ;) ) und bekomme die Adresse vom BMP.
Ich könnte auch ein um Faktor 3 ( und auch mehr ;) ) grössereres Format angeben und dann in der Anzeige runterrechnen ( Die eigentliche Datenmenge bleibt aber erhalten, um für den 'Zoom' noch genügend 'Spielraum' zu haben.
Für ein 256 Farb BMP in 800 x 600 könnten hier aber mal locker 40 MB Speicherplatz fällig sein ( wenn nicht gar mehr ).

Thema Threading : Mach ich.
Das heist, ich haue das 'RenderObjekt' komplett in nen Thread, synce das mit der Ausgabe. Nachteil : liegt zuviel aufm stack kanns wackeln ( nicht thread sicher ) und globale Varies sind verboten ( wer macht sowas überhaupt ;) ).

zeckensack

2003-01-18, 22:50:39

So, heute habe ich überhaupt nichts geschafft, habe gerade jemandem beim Boxen-Bau geholfen :D

Wuzel,
Tiefe Pixel-Zooms in Fraktalen sind keine besonders praktikable Idee =)
Es wäre schon besser, das Fraktal mit den passenden Parametern neu zu erzeugen.

Davon abgesehen ist's auch nicht wirklich schneller, ein 8000x6000-Fraktal zu erzeugen, und dann darin rumzuzoomen. Die Pixelanzahl killt die Performance.

Wünschenswert wären aber Zwischenergebnisse, also ein Signal vom Generator an die GUI, daß das Bild schonmal angezeigt werden kann, aber noch nicht fertig durchgerechnet ist. Dadurch kann der User anhand der Grobansicht schonmal entscheiden. Die Anzahl der Verfeinerungsschritte lässt sich nicht vorhersagen.

Wäre dann Quasi sowas:typedef unsigned char sample;
class
Generator //backt das Brot
{
public:
void set_fractal_params(...);
void set_image_dimensions(int width,int height);
bool refine_image(); //returns true if image has been completed
inline void start() { refine_image(); }
sample* get_image();

<...>
};

So in der Art :)

aths,
Die Optimierungen die du angegeben hast, werde ich morgen mal an einem 'normalen' Mandelbrötchen ausprobieren. Ich habe leider noch ein paar Probleme mit dem 'ExtremeFloat'-Datentyp, die ich noch angehen muß.

Multiplikation ist trivial und funktioniert jetzt zuverlässig, aber Subtraktion erfordert noch ziemlich viel Arbeit. Ebenso Addition von gemischt positiven und negativen Werten.
Die Addition von zwei positiven oder zwei negativen Zahlen funktioniert aber bereits :)

Wuzel

2003-01-19, 00:12:25

Originally posted by zeckensack
So, heute habe ich überhaupt nichts geschafft, habe gerade jemandem beim Boxen-Bau geholfen :D

Wuzel,
Tiefe Pixel-Zooms in Fraktalen sind keine besonders praktikable Idee =)
Es wäre schon besser, das Fraktal mit den passenden Parametern neu zu erzeugen.

Davon abgesehen ist's auch nicht wirklich schneller, ein 8000x6000-Fraktal zu erzeugen, und dann darin rumzuzoomen. Die Pixelanzahl killt die Performance.

Wünschenswert wären aber Zwischenergebnisse, also ein Signal vom Generator an die GUI, daß das Bild schonmal angezeigt werden kann, aber noch nicht fertig durchgerechnet ist. Dadurch kann der User anhand der Grobansicht schonmal entscheiden. Die Anzahl der Verfeinerungsschritte lässt sich nicht vorhersagen.

Wäre dann Quasi sowas:typedef unsigned char sample;
class
Generator //backt das Brot
{
public:
void set_fractal_params(...);
void set_image_dimensions(int width,int height);
bool refine_image(); //returns true if image has been completed
inline void start() { refine_image(); }
sample* get_image();

<...>
};

So in der Art :)

Hmm, dann doch gleich so :
In 'vorderster Front' gibt es bloss eine 'quasi Vorschau' die relativ flott gemacht wird ( niedrige auflösung etc. ).
Darin kann man auch bereiche markieren 'ranzoomen' etc.
Dann gibts da ne Option ->Render it<- wo man halt die 'finale' Ausgabe ( Auflösung etc. ) angeben kann. damit wird genau das was im View liegt sauberst gerendert ( darf dann auch dauern ).

Wär doch was ?

aths

2003-01-20, 14:38:06

zeckensack, gibt's Fortschritte?

OhneZ

2003-01-20, 19:10:49

Originally posted by aths
Gehört eigentlich eher ins Software-Forum, wegen der Spezifik frage ich aber mal hier.

Ich suche einen ultra genauen Mandelbrot-Renderer für Deep Zooms ins Apfelmännchen. 64 Bit FP reicht für meine Bedürfnisse nicht mehr aus :) Gibts da nicht was, was 128 Bit FP "emuliert"?

Nett wäre auch die Möglichkeit, Julia-Sets zu berechnen. Am besten wäre es, wenn sowohl inverse Mandelbrot- als auch Julia-Mengen möglich sind. (Invertierte Julia-Sets kann man herrlich verkleinern, doch auch hier versagt die 64-Bit-Genauigkeit immer dann, wenn es gerade interessant wird.)

Ich kenne und nutze bislang Fractint für DOS und Xaos für Windows.

Kleine Frage .... wozu braucht man einen Mandelbrot-Renderer ??

aths

2003-01-20, 19:11:59

Originally posted by OhneZ
Kleine Frage .... wozu braucht man einen Mandelbrot-Renderer ??Um Mandelbrot-Mengen berechnen zu lassen.

OhneZ

2003-01-20, 19:17:23

Originally posted by aths
Um Mandelbrot-Mengen berechnen zu lassen.

ja genau ?!?

sind das vieleicht diese Dinger die man aufzoomt und trotzdem kein Ende findet ??

wenn ja ..... es ist schön anzuschauen..... sehe aber sonst (leider) keinen Sinn drinn. ich kenn diese nur unter dem begriff fraktalgeneratoren.
das einzige was ich gehört habe ..... das codes, falls die damit erstellt werden könnten .....unknackbar sind.

aths

2003-01-20, 19:22:20

Originally posted by OhneZ
wenn ja ..... es ist schön anzuschauen..... sehe aber sonst (leider) keinen Sinn drinn. ich kenn diese nur unter dem begriff fraktalgeneratoren. Warum sollte es sonst noch einen Sinn geben?
Originally posted by OhneZ
das einzige was ich gehört habe ..... das codes, falls die damit erstellt werden könnten .....unknackbar sind. Prinzipiell ist jeder Code knackbar.

zeckensack

2003-01-21, 00:57:02

Originally posted by aths
zeckensack, gibt's Fortschritte?
Die Optimierungen sind jetzt drin. An die brutale Geschwindigkeit von Xaos reicht es aber bei weitem nicht heran.

Sieh selbst:
http://home.t-online.de/~zsack/brot.zip
(inklusive Quellcode)

Linke Maustaste zoomt rein, rechte Maustaste zoomt raus. Im DOS-Fensterchen werden die Fraktal-Parameter ausgespuckt.

Die Zahlen im Fenstertitel sind ein paar Statistiken zur Optimierung.

Wuzel

2003-01-21, 02:42:41

Hmm, also das Teil funzt, bloss wenn ich's selber kompilier ...
Naja vieleicht sollte ich jetzt erstmal pennen, GLUT ist drauf und funzt, nehm C++ .Net ( VS .Net Profesionall ) , ratter durch, in der Konsole hab ich Output, bloss das Glut Fenster bleibt 'black' :-(

Naja vermute mal das irgendwas mit meinem Glut Gedöns abspackt, den Fehler find ich schon noch.

PS : :D

Kompilieren...
rgbimage.cpp
mandelbrot.cpp
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\brot\src\mandelbrot.cpp(134) : warning C4018: '<=' : Konflikt zwischen signed und unsigned
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\brot\src\mandelbrot.cpp(143) : warning C4018: '<=' : Konflikt zwischen signed und unsigned
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\brot\src\mandelbrot.cpp(157) : warning C4018: '<=' : Konflikt zwischen signed und unsigned
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\brot\src\mandelbrot.cpp(163) : warning C4018: '<' : Konflikt zwischen signed und unsigned
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\brot\src\mandelbrot.cpp(171) : warning C4018: '<=' : Konflikt zwischen signed und unsigned
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\brot\src\mandelbrot.cpp(173) : warning C4018: '<=' : Konflikt zwischen signed und unsigned
main.cpp
bitfield2d.cpp
ExtremeFloat.cpp
Verknüpfen...

Brot - 0 Fehler, 6 Warnung(en)

zeckensack

2003-01-21, 02:49:51

Jajo, die Warnungen werde ich noch fixen :D

Btw, GLUT ist eh nur 'ne Übergangslösung.
Ich bin hier schon fleißig am basteln, das Bitfield2D benutze ich schon garnicht mehr (wertlose Optimierung), die ExtremeFloats funzen noch nicht richtig und werden deshalb auch noch nicht genutzt.

Der Code ist noch schwer in Bewegung, aber schau dir mal das Interface der Mandelbrot-Klasse an. Das isses ja, worum's hier eigentlich geht :)

Wuzel

2003-01-21, 02:54:42

Originally posted by zeckensack
Jajo, die Warnungen werde ich noch fixen :D

Btw, GLUT ist eh nur 'ne Übergangslösung.
Ich bin hier schon fleißig am basteln, das Bitfield2D benutze ich schon garnicht mehr (wertlose Optimierung), die ExtremeFloats funzen noch nicht richtig und werden deshalb auch noch nicht genutzt.

Der Code ist noch schwer in Bewegung, aber schau dir mal das Interface der Mandelbrot-Klasse an. Das isses ja, worum's hier eigentlich geht :)

Hab den fehler gefunden -> ich schnösel -> Pallete nich ins dir gepflanzt :D :D

Also ich bastel mal fleissig an nem SDI .....

zeckensack

2003-01-21, 03:38:08

Originally posted by Wuzel

Hab den fehler gefunden -> ich schnösel -> Pallete nich ins dir gepflanzt :D :D

Also ich bastel mal fleissig an nem SDI ..... Die Palettengeschichte gehört eigentlich auch in deinen Arbeitsbereich :D

Diese komische RgbImage-Klasse kann man dann auch komplett kicken.

Und: neue Version (http://home.t-online.de/~zsack/brot.zip) mit kleinen Bugfixes (im Log-Fenster), hoffentlich weniger Warnungen :D
und ganz wichtig: die Koordinaten für das Fraktal kommen jetzt als Center (zwei Zahlen) und Radius. Das Fraktal skaliert sich dann selbst zurecht, um ohne Verzerrungen ins Ausgabefenster zu passen.

get_r0(), get_i0(), get_dr() und get_di() fliegen in Kürze raus.

Wuzel

2003-01-21, 03:59:46

Originally posted by zeckensack
Die Palettengeschichte gehört eigentlich auch in deinen Arbeitsbereich :D

Jub, ging ja auch erstmal darum den Code einigermassen zu verstehen ;)
Morgen (heute :D) fahr ich dann die ersten Versuche das ins Doku zu pusten.
Denke das man damit dann schon nen weng arbeiten kann, drucken, konvertieren/saven etc. kommt dann hinterher.

zeckensack

2003-01-21, 06:49:48

Schon wieder neue Version (http://home.t-online.de/~zsack/brot.zip).

Das Interface steht jetzt. Dh so wie die Mandelbrot-Klasse jetzt ist, wird sie erstmal bleiben.

Änderungen:
Als allererstes kommt jetzt ein grobes Preview des kompletten Bildes.
Die Iterationstiefe kann jetzt geändert werden. Tasten Q und A.
neue Funktion Mandelbrot::zoom. Das Brötchen zoomt sich jetzt selbst. Nimmt Pixel-Koordinaten (Ursprung oben links) und einen Zoomfaktor. factor>1 zoomt rein, factor zwischen 0 und 1 zoomt raus. Siehe Maus-Handler in main.cpp.
nebenbei habe ich auch das falsche Gezoome bei nicht-quadratischem Fenster gefixt
Die Optimierungs-Statistiken sind raus (war eh nur Debug-Zeugs für mich)
Main.cpp aufgeräumt

Todo (für mich):
Endlich mal die ExtremeFloats fertig machen und einbauen :stareup:
refine() sollte etwas netter zum GUI sein, indem es nach einer festen Maximaldauer abbricht. ZB 100ms oder so.

Wuzel

2003-01-21, 07:49:47

Originally posted by zeckensack
Schon wieder neue Version (http://home.t-online.de/~zsack/brot.zip).

Das Interface steht jetzt. Dh so wie die Mandelbrot-Klasse jetzt ist, wird sie erstmal bleiben.

Änderungen:
Als allererstes kommt jetzt ein grobes Preview des kompletten Bildes.
Die Iterationstiefe kann jetzt geändert werden. Tasten Q und A.
neue Funktion Mandelbrot::zoom. Das Brötchen zoomt sich jetzt selbst. Nimmt Pixel-Koordinaten (Ursprung oben links) und einen Zoomfaktor. factor>1 zoomt rein, factor zwischen 0 und 1 zoomt raus. Siehe Maus-Handler in main.cpp.
nebenbei habe ich auch das falsche Gezoome bei nicht-quadratischem Fenster gefixt
Die Optimierungs-Statistiken sind raus (war eh nur Debug-Zeugs für mich)
Main.cpp aufgeräumt

Todo (für mich):
Endlich mal die ExtremeFloats fertig machen und einbauen :stareup:
refine() sollte etwas netter zum GUI sein, indem es nach einer festen Maximaldauer abbricht. ZB 100ms oder so.

Sag mal bist du eine lebendig gewordene Code Maschiene ???
Iss ja dicke, ich hab grad mal angefangen ( richtig Uhrig ) mit nem Bleistift und Papier in groben Zügen die Sache aufzuzeichnen, da schmeisst du die Versionen nur so hinterher ( *staun* ).

Zur Vorschaufunktion -> so ähnlich habe ich das gedacht.
Bloss : Fänd ichs schöner, wenn ich vom GUI aus die Vorschau steuern könnte, also nich ganz so extrem *pixelig*, dann wärs perfekt.
Denn dann würde ich wie gesagt erst alles per Preview machen, wenns für den Benutzer lustig wird kann er *Rendern* ....
Natürlich gibts für 'kleinere' grössen eine Autofunktion wos so abläuft wie's jetzt iss , so wie ich aber Aths verstanden habe, sollen auch Big Mama Formate drüber gehen und genau hier wäre obiges eventuell besser ?

Ansonsten *respekt*

Edit : Zoom Funktion gefällt mir ;)

Wuzel

2003-01-21, 08:19:01

*NO COMMENT* ;)

zeckensack

2003-01-21, 09:54:14

Originally posted by Wuzel
Sag mal bist du eine lebendig gewordene Code Maschiene ?
Iss ja dicke, ich hab grad mal angefangen ( richtig Uhrig ) mit nem Bleistift und Papier in groben Zügen die Sache aufzuzeichnen, da schmeisst du die Versionen nur so hinterher ( *staun* ).Tja, dafür kriegen andere Leute mehr Schlaf als ich ... :D

Zur Vorschaufunktion -> so ähnlich habe ich das gedacht.
Bloss : Fänd ichs schöner, wenn ich vom GUI aus die Vorschau steuern könnte, also nich ganz so extrem *pixelig*, dann wärs perfekt.
Denn dann würde ich wie gesagt erst alles per Preview machen, wenns für den Benutzer lustig wird kann er *Rendern* ....Joa, das ist eben ein fauler Kompromiß ;)
Im Moment wird die Preview erzeugt, indem das Bild in maximal 24*24 Pixel große Kacheln zerlegt wird. Jede dieser Kacheln kriegt dann einen Durchlauf der Funktion (genau in der Mitte) und wird mit dem Ergebniswert gefüllt. Der Nachteil bei der Geschichte ist, daß die Previewfunktion in der Form nicht von den Entropie-Optimierungen des 'richtigen' Generators profitiert und deswegen die Performance trotz drastisch reduzierter Pixelzahl schnell in den Keller gehen kann.

Die Kachelgröße ist übrigens in Mandelbrot::preview (mandelbrot.cpp) festgelegt, ich hab sie jetzt auch auf 10 Pixel gesenkt. Sieht etwas besser aus.

Wo wir gerade dabei sind, The Right Thing (tm) wäre es natürlich, das Preview zu erzeugen, indem man dem Generator einfach mitteilt, daß die Größe der Ausgabe zB statt (der echten) 800x600 Pixel nur (gelogene) 80x60 Pixel ist, und ihn dann normal rechnen lässt (wäre dann: fractal->set_size(80,60); ). Dann würde die Optimierung auch für's Preview greifen, Nachteil (?) wäre daß die GUI das Preview-Bildchen dann selbst skalieren muß.

Was aber allgemein ein Nachteil ist und bleibt, ist daß die Berechnungen für's Preview für die Katz waren, wenn das Bild später in voller Auflösung berechnet wird. So rekursive Verfeinerungen über's gesamte Grid sind im Moment nicht drin. Würde sich auch mit der eigentlich ganz gut funzenden Rechtecks-basierten Optimierung beißen.

Natürlich gibts für 'kleinere' grössen eine Autofunktion wos so abläuft wie's jetzt iss , so wie ich aber Aths verstanden habe, sollen auch Big Mama Formate drüber gehen und genau hier wäre obiges eventuell besser ????
Verstehe nicht ganz genau, was du meinst ... "Big Mama soll nur ganz grob vorberechnet werden und 320x240 Pixel gleich richtig"?

Ansonsten *respekt*

Edit : Zoom Funktion gefällt mir ;) Danke danke =)

zeckensack

2003-01-21, 09:57:10

Originally posted by Wuzel
*NO COMMENT* ;) Schick =)

Und jetzt noch ein Paletten-Management druff bidde :)

aths

2003-01-21, 10:19:06

Originally posted by zeckensack
Sieh selbst:
http://home.t-online.de/~zsack/brot.zip
Boah. Wow!!

edit1: Das Preview-Bild ist imo ok, auch die Daten nicht weiter verwendet werden.

edit2: Zoomen ginge "genauer", in dem mit der Maus ein Rahmen über die neue Area of Interest gezogen wird. Das Programm bestimmt den neuen Mittelpunkt und nimmt die längste Rechteckseite als Maß für die Ausdehnung des neuen Bildes.

edit3: DEF.PAL müsste eine DOS-Palette anzeigen, mit Blau am Anfang. Du hast R und B vertauscht :D

zeckensack

2003-01-21, 10:39:14

Originally posted by aths
Boah. Wow!!

edit1: Das Preview-Bild ist imo ok, auch die Daten nicht weiter verwendet werden.

edit2: Zoomen ginge "genauer", in dem mit der Maus ein Rahmen über die neue Area of Interest gezogen wird. Das Programm bestimmt den neuen Mittelpunkt und nimmt die längste Rechteckseite als Maß für die Ausdehnung des neuen Bildes.Ist eine Aufgabe für's Interface, ergo nicht für mich :D

edit3: DEF.PAL müsste eine DOS-Palette anzeigen, mit Blau am Anfang. Du hast R und B vertauscht :D Aha ?-)
Originally posted by aths
http://www.aths.net/files/paletten.zip

Enthält fortlaufen die Farbwerte R, G, B *hust*

:D

Außerdem: dito. Die eigentliche Grafikausgabe fällt (hoffentlich) nicht in meinen Zuständigkeitsbereich.
*rausred*

Wuzel

2003-01-21, 12:46:43

Originally posted by aths
Boah. Wow!!

edit1: Das Preview-Bild ist imo ok, auch die Daten nicht weiter verwendet werden.

edit2: Zoomen ginge "genauer", in dem mit der Maus ein Rahmen über die neue Area of Interest gezogen wird. Das Programm bestimmt den neuen Mittelpunkt und nimmt die längste Rechteckseite als Maß für die Ausdehnung des neuen Bildes.

edit3: DEF.PAL müsste eine DOS-Palette anzeigen, mit Blau am Anfang. Du hast R und B vertauscht :D

edit2:

Jupp, zwar nicht in der ersten Version, dann aber danach ....

edit3:
Joo da pass ich uff, nich das ich auch nen 'dreher' hinleg ;)
Wie ich das mit den Paletten genau mach -> hmmmm, zur Zeit fick ich mich mit DIB's ins Knie, scheint aber die einzig brauchbare 'Lösung'.
Alerdings muss ich dafür eine mehr oder minder perverse 'Speicherverwaltung' schreiben ( blödes Windoof ), habe alerdings eine schon fast vorgekochte Geschichte vor mir.
Bin mal gespannt wies kommt.
Ich habe nebenher schon mit gewissen Pallas rumexperimentiert, da liegt wirklich reizvolles in der Luft ;)

Wuzel

2003-01-21, 12:53:07

Originally posted by zeckensack

Außerdem: dito. Die eigentliche Grafikausgabe fällt (hoffentlich) nicht in meinen Zuständigkeitsbereich.
*rausred* [/SIZE]

Jup, so wies jetzt iss, komm ich gut klar mit.
Die Palas werde ich schon bändigen :naughty:

askibo

2003-01-21, 13:35:42

Originally posted by zeckensack
Änderungen:

Die Iterationstiefe kann jetzt geändert werden. Tasten Q und A.

Kannst du noch eine Option hinzufügen so dass sich die Iterationstiefe automatisch erhöht wenn man tiefer reinzoomt (wie z.B. bei WinCIG (http://www.th-soft.com/e_wincig.htm)) ?

Jaja, immer diese Leute mit ihren Extrawünschen :stareup: :D

aths

2003-01-21, 13:42:54

Originally posted by askibo
Kannst du noch eine Option hinzufügen so dass sich die Iterationstiefe automatisch erhöht wenn man tiefer reinzoomt (wie z.B. bei WinCIG (http://www.th-soft.com/e_wincig.htm)) ?Bringt wenig. Das erlaube ich mir als "alten Mandelbrot-Hasen" mal in den Raum zu werfen. Iterations-Tiefen passt man am besten von Hand an.

zeckensack

2003-01-21, 17:13:10

*gnarf*

Die gute Nachricht:
Die ExtremeFloats funzen jetzt gut genug, um damit das Mandelbrötchen zu berechnen.

Die schlechte Nachricht:
Trotz 192 Bit Mantisse liegt die erreichte Präzision nicht viel höher als mit gewöhnlichen doubles. Rein optisch würde ich 2 oder 3 Bits besser schätzen :|

Da muß ich irgendwo noch 'nen doofen Fehler drinhaben :(

Ganon

2003-01-21, 20:17:48

Hi,

nur mal ne Meldung!
Ich habs mal unter Linux mit Wine laufen lassen! Läuft soweit!

Wollt ihr es eigendlich Multiplattform machen? D.h. Windows,Linux,MAC?

Wuzel

2003-01-21, 20:24:40

Originally posted by Ganon
Hi,

nur mal ne Meldung!
Ich habs mal unter Linux mit Wine laufen lassen! Läuft soweit!

Wollt ihr es eigendlich Multiplattform machen? D.h. Windows,Linux,MAC?

Der C++/ASM Code von Zeckensack müsste eigentlich biss auf x86 Plattformunabhängig sein ,wenn ich das Win Gui fertich hab, schau ich mal.
X11 kann ich sowieso 10 mal schneller und besser als diese's doofe, unlogische MFC zeuch's ;)
Aber erst mal MFC , dann X11 ( eventuell ).

Zur Zeit krieg ich's nimme compiliert .. irgend ein include probi :(
Krieg ich aber schon noch hin, wär ja gelacht.

Ganon

2003-01-21, 20:30:03

Originally posted by Wuzel

Der C++/ASM Code von Zeckensack müsste eigentlich biss auf x86 Plattformunabhängig sein ,wenn ich das Win Gui fertich hab, schau ich mal.
X11 kann ich sowieso 10 mal schneller und besser als diese's doofe, unlogische MFC zeuch's ;)
Aber erst mal MFC , dann X11 ( eventuell ).

Zur Zeit krieg ich's nimme compiliert .. irgend ein include probi :(
Krieg ich aber schon noch hin, wär ja gelacht.

Das ist gut! Aber wenn es das noch für PowerPCs geben würde wäre es schön denn ich hab vor mir im Mai einen zu kaufen!

Dann schön mit Multi-Prozessor Unterstützung und wenn dann noch Altivec-Support drinne wäre..., aber das ist wohl zuviel verlangt!:D;)

aths

2003-01-21, 20:50:47

Originally posted by zeckensack
*gnarf*

Die gute Nachricht:
Die ExtremeFloats funzen jetzt gut genug, um damit das Mandelbrötchen zu berechnen.

Die schlechte Nachricht:
Trotz 192 Bit Mantisse liegt die erreichte Präzision nicht viel höher als mit gewöhnlichen doubles. Rein optisch würde ich 2 oder 3 Bits besser schätzen :|

Da muß ich irgendwo noch 'nen doofen Fehler drinhaben :( Grübel...

musst du wohl :) Die Unterschiede zwischen Single und Double sind jedenfalls schon gut sichtbar (so bei meinem gescheitertem Projekt) und ExtremeFloats müssten praktisch "unendlich" weit reichen (also dass vorher die Rechendauer limitiert, und nicht die Auflösung der Zahlen.)

aths

2003-01-21, 21:00:24

2 Ideen noch:

- Belege die "Innenfarbe" z.B. mit Index 0, und verwende diesen Index nicht mehr für "Schalen". (Ich möchte z.B. ein schwarzes Innere, aber ansonsten eine Palette ganz ohne schwarz!)

- Ist eine Art Triple Pass möglich? Das stell ich mir so vor:

1. Pass: Vorausschau-Bild (dessen Daten offenbar verworfen werden)

2. Pass: Bild in der Auflösung 0.5 x 0.5

3. Pass: Erneute Berechnung, diesmal in voller Auflösung. Das integrieren der bereits berechneten Daten sollte möglich sein (in jeder geraden Zeile jeden geraden X-Wert nicht mehr berechnen, sondern die fertige Farbe nutzen und gleich weiter machen.)

Wuzel

2003-01-21, 21:03:45

Housten, wir haben ein Problem :D

Entweder bin ich doof oder da ist was faul :

Über die MFC krieg ich folgenden Error, egal wie ichs dreh oder biege:
Kompilieren...
mandelineView.cpp
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\mandeline\brotcode\mandelbrot.h(60) : error C2143: Syntaxfehler : Es fehlt ',' vor '&'
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\mandeline\brotcode\mandelbrot.h(89) : error C2923: 'std::stack' : 'Rectangle' ist als Vorlagenargument '#1' ungültig, Typ erwartet
c:\Programme\Microsoft Visual Studio .NET\Vc7\PlatformSDK\Include\WinGDI.h(3338) : Siehe Deklaration von 'Rectangle'

Also in der MSDN hab ich nichts gefunden, jedenfalls nichts was mir weiterhelfen täte.
Ich weiss zumindest das es mit der ausgabe zusammenhängt und das ich hier eventuell was umschreiben muss ;).

Da das ganze jedoch in der mandelbrot.h abläuft, will ich vorher sicher gehen, nich das ich irgendwo aufm schlauch steh.

Lieber 2 mal dumm fragen ... :D

aths

2003-01-21, 21:18:23

zecki, die Koordinaten nutzen doch auch ExtremeFloats, oder?

zeckensack

2003-01-22, 06:59:28

Originally posted by aths
Grübel...

musst du wohl :) Die Unterschiede zwischen Single und Double sind jedenfalls schon gut sichtbar (so bei meinem gescheitertem Projekt) und ExtremeFloats müssten praktisch "unendlich" weit reichen (also dass vorher die Rechendauer limitiert, und nicht die Auflösung der Zahlen.) Jau, ich weiß. Ich habe jetzt in meiner Paranoia alle Daten des Mandelbrot-Generators auf 'precise' umgestellt, was ich mittels typedef dann testhalber als float, double, long double und ExtremeFloat definiert habe.

So ca bei den Koordinaten -1.29558/0.441480 habe ich dann ein paar Präzisionstests gemacht. float fangen an, ab Radius im Bereich 5e-06 die Grätsche zu machen, doubles gehen bis ca 5e-14, long doubles machen keinen Unterschied :|

und ExtremeFloats gehen bis 2e-14 ganz gut, also gerade mal ein läppsches Bit besser als doubles.

Mal schauen ?-)

zeckensack

2003-01-22, 07:02:56

Originally posted by Wuzel
Housten, wir haben ein Problem :D

Entweder bin ich doof oder da ist was faul :

Über die MFC krieg ich folgenden Error, egal wie ichs dreh oder biege:
Kompilieren...
mandelineView.cpp
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\mandeline\brotcode\mandelbrot.h(60) : error C2143: Syntaxfehler : Es fehlt ',' vor '&'
c:\Dokumente und Einstellungen\Wuzel\Eigene Dateien\mandeline\brotcode\mandelbrot.h(89) : error C2923: 'std::stack' : 'Rectangle' ist als Vorlagenargument '#1' ungültig, Typ erwartet
c:\Programme\Microsoft Visual Studio .NET\Vc7\PlatformSDK\Include\WinGDI.h(3338) : Siehe Deklaration von 'Rectangle'

Also in der MSDN hab ich nichts gefunden, jedenfalls nichts was mir weiterhelfen täte.
Ich weiss zumindest das es mit der ausgabe zusammenhängt und das ich hier eventuell was umschreiben muss ;).

Da das ganze jedoch in der mandelbrot.h abläuft, will ich vorher sicher gehen, nich das ich irgendwo aufm schlauch steh.

Lieber 2 mal dumm fragen ... :D Da er sich ansonsten nicht beschwert hat, gehe ich mal davon aus daß du die Header alle in der richtigen Reihenfolge eingebunden hast.

Vermutlich definiert VS.NET selbst einen Datentyp Rectangle. (wingdi.h)

Ich werd's mal umbenennen.

zeckensack

2003-01-22, 07:06:20

Originally posted by aths
zecki, die Koordinaten nutzen doch auch ExtremeFloats, oder? Mittlerweile wie gesagt alles.

Rein theoretisch braucht's die zusätzliche Präzision eigentlich erstmal nur zur Addition und Subtraktion, weil dort durch den Rechts-Shift der betragsmäßig kleineren Zahl Bits verlorengehen.

Das muß wirklich ein Fehler in meiner Logik sein. Gibt's irgendwo Online eine kurze algorithmische Zusammenfassung von Floating-Point-Operationen? Ich steh' gerade voll auf dem Schlauch ...

zeckensack

2003-01-22, 07:18:38

Originally posted by zeckensack
Gibt's irgendwo Online eine kurze algorithmische Zusammenfassung von Floating-Point-Operationen? Ich steh' gerade voll auf dem Schlauch ... Aha! (http://citeseer.nj.nec.com/cache/papers/cs/2925/http:zSzzSzwww.cs.cmu.eduzSz~quake-paperszSzrelatedzSzPriest.pdf/priest91algorithms.pdf) =)
Oho (http://www.cs.wisc.edu/~smoler/x86text/lect.notes/arith.flpt.html) :o

zeckensack

2003-01-22, 08:43:19

Üpp
brot.zip (http://home.t-online.de/~zsack/brot.zip)
brot_extreme.zip (http://home.t-online.de/~zsack/brot_extreme.zip)

Die 'normale' Variante benutzt doubles, die 'extreme' ExtremeFloats (immer noch kaputt). Ist wirklich schrecklich lahm, ich dachte ihr solltet euch das mal ansehen :D

Änderungen: Paletten werden jetzt richtig herum eingelesen (für aths)
Die Klasse Rectangle heißt jetzt Section (für Wuzel)
Das grobe Preview ist erstmal wieder raus
Basteleien am ExtremeFloat (in progress)

zeckensack

2003-01-22, 08:57:30

Originally posted by aths
2 Ideen noch:

- Belege die "Innenfarbe" z.B. mit Index 0, und verwende diesen Index nicht mehr für "Schalen". (Ich möchte z.B. ein schwarzes Innere, aber ansonsten eine Palette ganz ohne schwarz!)
Das ist bereits so. Oder besser gesagt:
Beim Erreichen der maximalen Iterationstiefe wird als Ergebnis 0 gespeichert. Sonst nie. Erfolgreiche Berechnungen liefern immer Ergebnisse in [1...255].
Das einzige was dann noch fehlt, ist daß Paletteneintrag #0 schwarz sein muß. Bei der von dir gelieferten DEF.PAL ist auch das gegeben.

- Ist eine Art Triple Pass möglich? Das stell ich mir so vor:

1. Pass: Vorausschau-Bild (dessen Daten offenbar verworfen werden)

2. Pass: Bild in der Auflösung 0.5 x 0.5

3. Pass: Erneute Berechnung, diesmal in voller Auflösung. Das integrieren der bereits berechneten Daten sollte möglich sein (in jeder geraden Zeile jeden geraden X-Wert nicht mehr berechnen, sondern die fertige Farbe nutzen und gleich weiter machen.) Das ist bestimmt möglich. Ich will mich aber zuerst mal auf die ... hmmm Numerik-Probleme konzentrieren :)

Gold Plating gibt's erst später ;)

aths

2003-01-22, 13:27:28

Zur Optimierung: Irgendwie malst du immer neue Rechteck-Ränder? Wäre es nicht besser, die bisherigen Ränder zu nutzen und lediglich noch die Unterteilungs-Linie in zwei Hälften neu zu berechnen?

Edit: Zu den ExtremeFloats. Ich sehe da, wo eigentlich das Apfelmännchen sein sollte, folgendes:

aths

2003-01-22, 13:33:43

Bei der Extreme-Version stimmen die X-Koordinaten von -1 - 0 nicht.

zeckensack

2003-01-22, 15:04:25

Originally posted by aths
Bei der Extreme-Version stimmen die X-Koordinaten von -1 - 0 nicht. Kann ich bestätigen.

Wie sagt man doch so schön:
Der Reifen platzt an der schwächsten Stelle :D

Jedenfalls arbeite ich daran. Ich habe so den Verdacht, daß das alles (und noch viel meeeeheer) an falscher Behandlung von Nullen liegt.

Eine Runde Geduld und Mitleid bitte, Extremfloat.cpp hat jetzt knapp 800 Zeilen und das meiste davon ist Inline-Assembler ...

zeckensack

2003-01-22, 15:08:20

Originally posted by aths
Zur Optimierung: Irgendwie malst du immer neue Rechteck-Ränder? Wäre es nicht besser, die bisherigen Ränder zu nutzen und lediglich noch die Unterteilungs-Linie in zwei Hälften neu zu berechnen?Stimmt. Am Anfang hatte ich es so, dann habe ich mich aber doch hinreißen lassen, die Logik zur Überprüfung "Habe ich das hier schon ausgerechnet?" rauszukicken.

Ich versuch's später wieder. Die Prioritäten liegen momentan anders =)

Unregistered

2003-01-22, 16:37:59

also für den assembler code müsstest ja nenn extra orden kriegen. es gibt nichts schlimmeres als das :)

zeckensack

2003-01-22, 18:32:43

Thx @ Unreg :)

Mittlerweile funzt's sogar, soll heißen daß 'meine' Floats jetzt numerisch stabil sind.

Ich bau jetzt noch den Pixel-Cache wieder druff und versuche die alte Optimierung.

Dann mache ich mal daran, die Rundungsfehler zu minimieren. Ich habe so den Verdacht, daß das dazu führt, daß präzisionsmäßig bisher nichts dabei herausgekommen ist ?-)

zeckensack

2003-01-23, 00:56:29

*jaul*

Es war im Endeffekt der implizite Konvertierungs-Operator. Der Compiler hat sich netterweise bei der Arithmetik öfter mal dazu entschieden, alles nach double zu konvertieren, anstatt umgekert mit voller Präzision zu arbeiten :bad1:

Apropos, noch was zur Demonstration. Man achte auf den Wertebereich ... über hundert Bits im Minus und immer noch keine Artefakte.

aths

2003-01-23, 11:43:00

Und wo kann man das downloaden?

zeckensack

2003-01-23, 13:37:22

Sorry,

Hier isses (http://home.t-online.de/~zsack/brot_extreme.zip).
Änderungen: ExtremeFloats funzen
Generator startet mit Ursprung 0/0, Radius 2 (Vollansicht des Apfelmännchens)
Mittels gedrückter SHIFT-Taste kann der Zoomfaktor erhöht werden
Die Leertaste bringt die Ansicht zurück zum Ursprung
Preview ist wieder drin
Die Optimierung wurde leicht geändert (siehe Vorschlag von aths)
Das ganze ist jetzt sch*** lahm :bäh:

Zur Erinnerung:
Q verdoppelt die maximale Iterationstiefe
A halbiert die maximale Iterationstiefe
Linksklick zoomt hinein
Recktsklick zoomt raus
Das Fenster darf beliebig skaliert werden

aths

2003-01-23, 17:38:51

Das Vorschaubild ist wieder da :)

Wird das eigentlich auch mit Optimierung berechnet?

zeckensack

2003-01-23, 17:52:51

Originally posted by aths
Das Vorschaubild ist wieder da :)

Wird das eigentlich auch mit Optimierung berechnet? Nein. Es wird in einem groben Raster 'brute force' durchgerechnet.
Die ermittelten Werte werden allerdings nicht verworfen. Ob das für den detaillierten Durchlauf etwas bringt, wage ich aber zu bezweifeln. Der Rechtecks-Split funktioniert genau wie später bei der vollen Berechnung und die Werte für's Preview werden genau in der Mitte abgegriffen. Dh daß die Arbeit des Previews erst dann wieder verwertet wird, wenn der optimierte Durchlauf bei Rechtecksgröße nx1 angekommen ist, also ganz am Ende.
Ich schlage immer noch vor, das Preview in der jetzigen Form wegfallen zu lassen, und das Brötchen stattdessen in kleiner Auflösung normal durchzurechnen.

Wie du sicher festgestellt hast, ist das Rechnen mit brauchbaren Iterationstiefen unerträglich langsam. Jetzt wäre es vielleicht mal an der Zeit, weitere Optimierungen aus Xaos oder Fractint zu 'klauen'. Die ExtremFloats selbst werden sich IMO kaum noch beschleunigen lassen. Das einzige was da wirklich was bringen könnte, wäre eine 64bit-Maschine :D

x-dragon

2003-01-23, 18:03:17

Originally posted by zeckensack
...
Das Fenster darf beliebig skaliert werden Muss aber anscheind eine Mindestgröße haben, damit es nicht verzerrt(s. Anhang).

Aber das ist echt schon genial, bei sowas mal zuzuschauen wie sich sowas entwickelt. Progammierer bin ich zwar auch, hab aber von C kaum Ahnung und von Assembler keinen blassen Schimmer. Und in den Zahlenbereichen bewege ich mich auch recht selten :D.

askibo

2003-01-23, 18:05:19

Saubere Arbeit, zeckensack.
Respekt =)

Ein paar Optimierungen wären aber gut ;)
Die Geschwindigkeit mit hoher Iterationstiefe erinnert mich momentan noch irgendwie dann an das erste Mandelbrot-Programm auf meinem Amiga. *Nostalgiegefühle* :D

Originally posted by zeckensack
..Das einzige was da wirklich was bringen könnte, wäre eine 64bit-Maschine :D

hrhr, endlich mal eine sinnvolle Anwendung für den Athlon64 :naughty:

zeckensack

2003-01-23, 18:29:04

Originally posted by X-Dragon
Muss aber anscheind eine Mindestgröße haben, damit es nicht verzerrt(s. Anhang).Was ist das für'ne Grafikkarte?
Bei mir funzt das, alles was man dafür braucht ist ein halbwegs vernünftiger OpenGL1.0-Treiber, also wirklich nichts dolles :|

Aber das ist echt schon genial, bei sowas mal zuzuschauen wie sich sowas entwickelt. Progammierer bin ich zwar auch, hab aber von C kaum Ahnung und von Assembler keinen blassen Schimmer. Und in den Zahlenbereichen bewege ich mich auch recht selten :D. Hrhr, hat Spaß gemacht, aber so langsam reicht's fast :D

zeckensack

2003-01-23, 18:32:12

Originally posted by askibo
Saubere Arbeit, zeckensack.
Respekt =)

Ein paar Optimierungen wären aber gut ;-)
Die Geschwindigkeit mit hoher Iterationstiefe erinnert mich momentan noch irgendwie dann an das erste Mandelbrot-Programm auf meinem Amiga. *Nostalgiegefühle* :DSagt dir Schneider CPC464 etwas? Oder Z80 @ 4MHz? Auf sowas hatte ich auch mal ein Mandelbrötchen. Da dauerte die Vollansicht mit Iterationstiefe 20 schon 'ne halbe Stunde :D

Ich muß gestehen, daß ich keinen Plan von 'modernen' Optimierungsstrategien für dieses Rechenproblem habe. Bin ja kein Mathematiker ...
hrhr, endlich mal eine sinnvolle Anwendung für den Athlon64 :naughty: Ganz gaynau :)

x-dragon

2003-01-23, 18:35:27

Originally posted by zeckensack
Was ist das für'ne Grafikkarte?
Bei mir funzt das, alles was man dafür braucht ist ein halbwegs vernünftiger OpenGL1.0-Treiber, also wirklich nichts dolles :|

Hrhr, hat Spaß gemacht, aber so langsam reicht's fast :D Ähm, wenn das daran liegt nimm ich natürlich alles zurück. Ich hab hier irgend so einen alten Intel-Chip. Ich dachte ja nur, weil es bei größeren Einstellungen einwandfrei funktionierte (wenn auch etwas langsam :D ).

aths

2003-01-23, 19:04:06

Originally posted by zeckensack
Ich schlage immer noch vor, das Preview in der jetzigen Form wegfallen zu lassen, und das Brötchen stattdessen in kleiner Auflösung normal durchzurechnen.Ich schlage dann einen adaptiven Verfeinerungsalgo vor. Er rechnet das Bild erst in 1/32 x 1/32 größe (gleich mit Optimierung), dann in 1/16 x 1/16 usw und verwendet jeweils die bisher bekannten Daten. Durch die Zweier-Verfeinerung sollte das auch ganz gut rekursiv zu machen sein.

Das gute hieran ist übrigens die mögliche Erweiterung fürs AA :) (optionales Rendern in der Auflösung 2x2 bishin zu 4x4.)

askibo

2003-01-23, 19:59:49

Originally posted by zeckensack
Was ist das für'ne Grafikkarte?
Bei mir funzt das, alles was man dafür braucht ist ein halbwegs vernünftiger OpenGL1.0-Treiber, also wirklich nichts dolles :|

Der Fehler von X-Dragon tritt bei mir auch auf, hab eine GF4 mit 42.01 Treibern.
Edit: unter Win2k SP3

Außerdem verabschiedet sich das Programm ab und zu.
Edit: Verabschiedet sich nur beim skalieren, sonst nicht.

Edit2: Schwachsinn gelöscht

x-dragon

2003-01-23, 20:52:42

Habs nochmal zu Hause getestet mit Geforce2MX(42.01) unter WindowsXP SP1, und wenn eine bestimmte Breite unterschritten wird (die höhe scheint egal zu sein) verzerrt das Bild wie oben.

Als ich etwas zu viel dran rumgespielt hab(an der Größe), hatte ich plötzlich ein Bluescreen mit der Meldung "Windows hat ein Problem festgestellt ... wurde sicherheitshalber runtergefahren ..." und mit vielen netten Tips von B wie BIOS-Update bis zu V wie VGA-Karte auswechseln :).

2003-01-23, 21:00:43

Originally posted by askibo

Der Fehler von X-Dragon tritt bei mir auch auf, hab eine GF4 mit 42.01 Treibern.
Edit: unter Win2k SP3

Außerdem verabschiedet sich das Programm ab und zu.
Edit: Verabschiedet sich nur beim skalieren, sonst nicht.

Same here.

Obige Verzerrungen beim Hoch- und Runterskalieren des Bildes, irgendwann ist´s ihm dann wohl genug und es crasht (Win98, GF4, Det42.01).

zeckensack

2003-01-23, 21:22:51

Interessanterweise kann's meine Gf2MX auch nicht :|
Da ist AFAIR der 30.82er Deto drauf.

Alles was ich mit der Graka mache, ist das hier
glRasterPos2f(-1.0f,1.0f);
glPixelZoom(1,-1);
glPixelTransferi(GL_UNPACK_ALIGNMENT,1);

glDrawPixels(output_image->get_width(),
output_image->get_height(),
GL_RGB,GL_UNSIGNED_BYTE,
output_image->get_rgb_data());Mit Verlaub, das ist definitiv richtig.

Goldene NVIDIA-Treiber? *eg*

edit: Kommando zurück, Fehler gefunden

x-dragon

2003-01-23, 21:28:23

Wenn man das Programm normal laufen läßt funktioniert es einwandfrei (soweit ich das beurteilen kann) :). Getestet hab ich es bis zu einem Radius von: 6.10351563 e-005

zeckensack

2003-01-23, 21:43:18

An alle, die den Fehler haben:
Bitte in fünf Minuten neu runterladen.
http://home.t-online.de/~zsack/brot_extreme.zip

Außerdem hat's jetzt ein Speicherleck weniger :D

x-dragon

2003-01-23, 22:02:02

Originally posted by zeckensack
An alle, die den Fehler haben:
Bitte in fünf Minuten neu runterladen.
http://home.t-online.de/~zsack/brot_extreme.zip

Außerdem hat's jetzt ein Speicherleck weniger :D Meine ersten Tests sind erfolgreich abgeschlossen und von mir gibts erstmal ein http://mysmilies.no-ip.com/mysmilies/biggthumpup.gif

[edit]
liegt das eigentlich an Windows oder vielleicht an meiner Grafikkarte, das er bei Größenänderungen des Fensters mit dem zeichnen des Rahmens nicht mitkommt?

aths

2003-01-23, 22:40:28

Das ist eine sehr gute Sache bis jetzt, zeckensack. Ich bin "außen" (nahe -2) und bei E-028, und keinerlei Anzeichen von Genauigkeitsproblemen. Solche Strukturen zu sehen war mir bislang nicht möglich:

zeckensack

2003-01-23, 22:53:50

Originally posted by X-Dragon
Meine ersten Tests sind erfolgreich abgeschlossen und von mir gibts erstmal ein http://mysmilies.no-ip.com/mysmilies/biggthumpup.gif

[edit]
liegt das eigentlich an Windows oder vielleicht an meiner Grafikkarte, das er bei Größenänderungen des Fensters mit dem zeichnen des Rahmens nicht mitkommt?
Das liegt an meinem Programm im Zusammenspiel mit GLUT. Der Fensterinhalt wird erst dann neu gezeichnet, wenn die Vergrößerung des Rahmens abgeschlossen ist. Ich hoffe du kannst es verschmerzen :)

zeckensack

2003-01-23, 22:54:32

Originally posted by aths
Das ist eine sehr gute Sache bis jetzt, zeckensack. Ich bin "außen" (nahe -2) und bei E-028, und keinerlei Anzeichen von Genauigkeitsproblemen. Solche Strukturen zu sehen war mir bislang nicht möglich: Bei e-50 wirst du deine Präzisionsprobleme bekommen, da war ich auch schon :)

AlfredENeumann

2003-01-24, 00:20:23

Originally posted by aths
Das ist eine sehr gute Sache bis jetzt, zeckensack. Ich bin "außen" (nahe -2) und bei E-028, und keinerlei Anzeichen von Genauigkeitsproblemen. Solche Strukturen zu sehen war mir bislang nicht möglich:

wie lange hast du dich denn da durchgeklickt ?

@zeckensack

Kann man den ganzen spaß auch irgendwie beschleunigen ?

Endorphine

2003-01-24, 00:31:14

Respekt! Wirklich stark, was du da innerhalb kürzester Zeit scheinbar so aus dem Ärmel schüttelst... :o

Unregistered

2003-01-24, 00:54:57

naja irgendwie krieg ich hier auf einmal ein komsiches bild und weis ned an was das liegt??!!

http://www.badct.de/image.php?id=363

Unregistered

2003-01-24, 00:55:36

ich meine das rechts oben

aths

2003-01-24, 15:01:25

zs,

ein Verfeinerungs-Algo wäre echt nütztlich. Ich möchte oft nur tieeef zoomen, da brauche ich nicht gleich die volle Auflösung. Wenn man immer in 2-er Schritten verfeinert sollte die Auswahl, ob man neu berechnet oder fertige Daten nimmt auch relativ unproblematisch sein. Du müsstest du die Vorschau-Bilder entsprechend hochskalieren, damit sie gleich die richtige Fläche einnehmen.

zeckensack

2003-01-24, 22:35:50

Hopplahopp (http://home.t-online.de/~zsack/brot_extreme.zip)
Preview mal anders
Das Brötchen erzeugt jetzt endlich keine CPU-Last mehr, nachdem es fertig gerechnet hat
Das Interface reagiert schneller. Grund:
Mandelbrot::refine_image beendet sich jetzt nach einer mehr oder weniger konstanten Zeit (ist aber Systemabhängig). Auf meinem Rechner läuft das ganze ca mit durchaus angenehmen 6 'fps'.
Der Fenstertitel zeigt jetzt an, ob noch gerechnet wird, oder ob das Bild fertig ist
Beim Erhöhen der Iterationstiefe werden bereits fertige werte 'recycelt'. Bei Verringern nicht (ist Absicht)

zeckensack

2003-01-24, 22:39:03

Originally posted by Unregistered
naja irgendwie krieg ich hier auf einmal ein komsiches bild und weis ned an was das liegt??!!

http://www.badct.de/image.php?id=363 Das sind so gaaaanz langsam die Regionen, wo die Präzision nicht mehr reicht :naughty:

Du bist bei e-48, Mandelbrotgeneratoren mit 'normalen' floats kommen nur bis ca e-8. Zaubern kann ich leider auch nicht :)

zeckensack

2003-01-24, 22:44:46

Originally posted by AlfredENeumann
wie lange hast du dich denn da durchgeklickt ?Shift drücken, dann geht's schneller ;)

@zeckensack

Kann man den ganzen spaß auch irgendwie beschleunigen ? Jau. Eine angepaßte Sledgehammer-Version sollte bei gleichem Takt mindestens dreimal so schnell sein ...

Wenn dich das Thema weiter interessiert, dann versuch's vielleicht erstmal mit Xaos und/oder Fractint. Die sind naturgemäß viel schneller (dafür hapert's dann halt an der Präzision).

zeckensack

2003-01-24, 23:04:53

Lustiger Benchmark zu ExtremeFloats:#include <time.h>
#include "common.h"
#include "ExtremeFloat.h"
#include "stdio.h"

int
main()
{
ExtremeFloat a,b,c;
// long double a,b,c;
// double a,b,c;
// float a,b,c;

double t=0.0;

uint flops=0;

clock_t start=clock();

while ((t<5.0)&&(flops<(1<<31)))
{

a=1.0;
b=1.777493;
c=0.12094893203792;

for (int i=0;i<10000;++i)
{
a*=a;
a+=b;
a-=c;
}

clock_t end=clock();
flops+=30000;

t=double(end-start)/CLOCKS_PER_SEC;
}

double flops_per_sec=flops/t;

printf("%g flops\n",flops_per_sec);
printf("timer resolution: %u ticks/s\n",CLOCKS_PER_SEC);
return(0);
}

Ergebnis auf meinem System:
floats/doubles/long doubles jeweils 2.4 GFlops
ExtremeFloats 4.6 MFlops

aths

2003-01-24, 23:07:47

Originally posted by zeckensack
Hopplahopp (http://home.t-online.de/~zsack/brot_extreme.zip)
Preview mal anders
Das Brötchen erzeugt jetzt endlich keine CPU-Last mehr, nachdem es fertig gerechnet hat
Das Interface reagiert schneller. Grund:
Mandelbrot::refine_image beendet sich jetzt nach einer mehr oder weniger konstanten Zeit (ist aber Systemabhängig). Auf meinem Rechner läuft das ganze ca mit durchaus angenehmen 6 'fps'.
Der Fenstertitel zeigt jetzt an, ob noch gerechnet wird, oder ob das Bild fertig ist
Beim Erhöhen der Iterationstiefe werden bereits fertige werte 'recycelt'. Bei Verringern nicht (ist Absicht) Ich sehe nix von den neuen Features. Entweder hast du es nicht richtig hochgeladen, oder der Proxy-Cache hält mich zum Narren...

edit: Es lag an shice Cache.

edit2: Ziemlich geile Sache, der Bildaufbau. Das ist der erste adaptive Mandelbrot-Renderer den ich kenne, der keine "Optimmierungen" hat die zu Fehlern führen können. Obwohl: Füllst du da nicht "zu früh"? Verfeinerst du bereits gefüllte Blöcke ggf. noch?

zeckensack

2003-01-24, 23:27:33

Originally posted by aths
zs,

ein Verfeinerungs-Algo wäre echt nütztlich. Ich möchte oft nur tieeef zoomen, da brauche ich nicht gleich die volle Auflösung. Wenn man immer in 2-er Schritten verfeinert sollte die Auswahl, ob man neu berechnet oder fertige Daten nimmt auch relativ unproblematisch sein. Du müsstest du die Vorschau-Bilder entsprechend hochskalieren, damit sie gleich die richtige Fläche einnehmen. Ich wollte die Arbeit am Interface ja eigentlich einstellen :D

Das 'neue' Preview finde ich in dieser Hinsicht eigentlich schon ganz brauchbar. Der Witz bei der Geschichte ist, daß es gar kein Preview ist, sondern ein ganz normaler Durchlauf. Der wichtigste Unterschied zur letzten Preview-losen Version ist, daß ich von einem stack auf eine deque (=double ended queue) gewechselt habe. Das führt dazu, daß der Algorithmus nicht ewig in einer Ecke rumgrast, sondern mehrfach über's Bild huscht. Da wo er schnell solide Rechtecke findet, füllt er diese schonmal aus, man bekommt also tatsächlich eine Grobansicht der 'einfachen' Regionen des Bildes.

Jetzt fragst du dich sicher, ob man in den 'schwierigen' Regionen nicht auch gefüllte Flächen kriegen kann, statt einzelne Pixel. Man kann, aber ich halte das nicht für klug. Die Anforderungen an Speicherbandbreite und Cache gehen dann endgültig durch's Dach, weil fast alle Pixel mehrfach geschrieben werden (genauer: log2(Auflösung)). Und das wären zum Großteil Cache-Misses. Für ein 1024er Vollbild wäre eine CPU mit 1MB Cache gerade noch angemessen ...

Btw habe ich auch den Profiler drüber rutschen lassen.
Erwartungsgemäß frißt die Auswertung des Fraktals >95% der Laufzeit. Davon sind aber interessanterweise nur 65% ExtremeFloat-Arithmetik. Die restlichen 30% sind Speicher-Traffic.

zeckensack

2003-01-24, 23:30:54

Originally posted by aths
edit2: Ziemlich geile Sache, der Bildaufbau. Das ist der erste adaptive Mandelbrot-Renderer den ich kenne, der keine "Optimmierungen" hat die zu Fehlern führen können. Obwohl: Füllst du da nicht "zu früh"? Verfeinerst du bereits gefüllte Blöcke ggf. noch? Ich fülle erst, wenn alle auf dem Rechteck-Rand liegenden Samples untersucht und für gleich befunden wurden. Also keinesfalls zu früh, höchstens zu spät ;)

Freut mich daß es dir gefällt =)

aths

2003-01-24, 23:38:55

Originally posted by zeckensack
Jetzt fragst du dich sicher, ob man in den 'schwierigen' Regionen nicht auch gefüllte Flächen kriegen kann, statt einzelne Pixel. Man kann, aber ich halte das nicht für klug. Die Anforderungen an Speicherbandbreite und Cache gehen dann endgültig durch's DachIch habe einen Pentium4 :naughty:

Du kannst es ja umschaltbar machen :)
Originally posted by zeckensack
Ich fülle erst, wenn alle auf dem Rechteck-Rand liegenden Samples untersucht und für gleich befunden wurden. Also keinesfalls zu früh, höchstens zu spät ;)Das verstehe ich von der Logik nicht ganz. Er geht erst grob rüber und wird dann immer feiner. Hebt er sich die schwierigen Bereiche auf und berechnet erst den vollen Rand der "leichten" Stellen?

zeckensack

2003-01-25, 00:06:08

Originally posted by aths
Ich habe einen Pentium4 :naughty:

Du kannst es ja umschaltbar machen :)Na dann hast du ja Glück, daß ich (fast) keinen FPU-Code drin habe :naughty:
Das verstehe ich von der Logik nicht ganz. Er geht erst grob rüber und wird dann immer feiner. Hebt er sich die schwierigen Bereiche auf und berechnet erst den vollen Rand der "leichten" Stellen? Sprichst du C++? Steht alles drin :)

Das läuft so ab, daß er sich einen Referenzwert schnappt und dann anfängt, die Kanten des Rechtecks zu untersuchen. Sobald ein Sample nicht mit dem Referenzwert übereinstimmt, wird die Bearbeitung des Rechtecks abgebrochen, es wird in zwei Hälften zerlegt und für später abgespeichert.

Wenn doch alle Samples auf den Kanten passen, dann wird das Rechteck gefüllt. Es wird weder weiter unterteilt, noch gespeichert. Deswegen werden große Flächen mit gleicher 'Farbe' zuerst fertig.

Zuerst hatte ich das 'für später abspeichern' mit einem Stack implementiert, das hat dann dazu geführt daß das Bild 'von oben links kam'. Die deque kannst du dir als zwei Stacks vorstellen. Ein Arbeits-Stack, und ein 'für später'-Stack. Wenn der Arbeits-Stack leer ist, werden die beiden Stacks vertauscht. Ping Pong :)

aths

2003-01-25, 01:35:36

Originally posted by zeckensack
Na dann hast du ja Glück, daß ich (fast) keinen FPU-Code drin habe :naughty:
Sprichst du C++? Steht alles drin :)

Das läuft so ab, daß er sich einen Referenzwert schnappt und dann anfängt, die Kanten des Rechtecks zu untersuchen. Sobald ein Sample nicht mit dem Referenzwert übereinstimmt, wird die Bearbeitung des Rechtecks abgebrochen, es wird in zwei Hälften zerlegt und für später abgespeichert.

Wenn doch alle Samples auf den Kanten passen, dann wird das Rechteck gefüllt. Es wird weder weiter unterteilt, noch gespeichert. Deswegen werden große Flächen mit gleicher 'Farbe' zuerst fertig.

Zuerst hatte ich das 'für später abspeichern' mit einem Stack implementiert, das hat dann dazu geführt daß das Bild 'von oben links kam'. Die deque kannst du dir als zwei Stacks vorstellen. Ein Arbeits-Stack, und ein 'für später'-Stack. Wenn der Arbeits-Stack leer ist, werden die beiden Stacks vertauscht. Ping Pong :) Du bist ein gerissener Hund :naughty: Problematisch ist hier nur, wenn man aus Versehen im Core anfängt und eine hohe Iterationstiefe hat. (Hohe Tiefe? Naja...) Dann wird es wohl erst mal eine Weile dauern ehe der Rest zum Zuge kommt...

zeckensack

2003-01-25, 02:33:15

Originally posted by aths
Du bist ein gerissener Hund :naughty: Problematisch ist hier nur, wenn man aus Versehen im Core anfängt und eine hohe Iterationstiefe hat. (Hohe Tiefe? Naja...) Dann wird es wohl erst mal eine Weile dauern ehe der Rest zum Zuge kommt... Das ist sooo schlimm nicht. Das kannst du gerne mal ausprobieren, der komplett schwarze Kern wird als eben solcher erkannt, und nur der Rand wird durchgerechnet.

Wenn man es natürlich übertreibt ...
Mein kleiner Athlon schafft zB ca 300000 Iterationen pro Sekunde. Wenn ich also jetzt 300000 als maximale Iterationstiefe setze, und genau in den Kern zoome, dann dauert das 2398 Sekunden, aka 40 Minuten, bis der Spuk vorbei ist. In der Zeit wird das Programm auch nicht auf User-Wünsche reagieren :naughty:

Lost Prophet

2003-01-25, 11:19:16

also die ältere version mit den rechtecken gefiel mir seeeeeeeeeeeeeeeeeeeeeeeeeeeehr viel besser als das sich aufpixelnde

ansonsten wie immer *thumbsup*

noch ein kleier vorschlag:

so eine Art Lasso (Bezeichung is sicher falsch, egal ich mein dieses Rechteck das man mit der maus von punkt a nach punkt b zieht) wie in Paint, Photoshop, etc und am Desktop, mit der man sich einfach den bereich einrahmen kann den man gerne sehen würde

cya axel

zeckensack

2003-01-25, 14:24:01

Originally posted by Purple_Stain
also die ältere version mit den rechtecken gefiel mir seeeeeeeeeeeeeeeeeeeeeeeeeeeehr viel besser als das sich aufpixelndeKann ich schon verstehen.
Da mußte ich halt abwägen zwischen "Dauer bis zum brauchbaren Preview" und "Dauer bis alles fertig ist".
Ich habe mich jetzt halt für's Preview entschieden, aths' Argument, daß man oft einfach schnell noch weiter reinzoomen will und das Bild garnicht fertig machen will hat mich letztendlich überzeugt.

Originally posted by Purple_Stain
noch ein kleier vorschlag:

so eine Art Lasso (Bezeichung is sicher falsch, egal ich mein dieses Rechteck das man mit der maus von punkt a nach punkt b zieht) wie in Paint, Photoshop, etc und am Desktop, mit der man sich einfach den bereich einrahmen kann den man gerne sehen würde

cya axel Ehrlich gesagt halte ich den aktuell implementierten Zoom für sinnvoller. Der beachtet nämlich (im Gegensatz zum Rahmen-aufziehenden User) das Seitenverhältnis des Fensters. Und schnell genug 'rein' kommt man mit SHIFT+Linksklich IMO auch.

Ganz davon abgesehen wär's sehr anstrengend, das jetzt nochmal umzukrempeln :D
Für User-Interfaces bin ich nicht der Typ, das hatte ich ja schon gesagt.

zeckensack

2003-01-25, 15:54:42

Üpp (http://home.t-online.de/~zsack/brot.zip)
Das Brötchen wählt jetzt automatisch zwischen ExtremeFloats und 'normalen' doubles. Dh daß es bei geringer Vergrößerung viel schneller ist, trotzdem ist die volle Präzision bei Bedarf verfügbar. :)
Cache-freundlicher.

brot_extreme.zip habe ich übrigens von meinem Account gelöscht. Gibt's nicht mehr. Nur noch brot.zip.
Die neue Version vereint die Funktion der beiden.

aths

2003-01-25, 17:11:45

zecki, kannst du nicht einen aktivierbaren Alternativ-Modus einbauen, der auch beim Kern abbricht und erst mal weiter macht?

zeckensack

2003-01-25, 17:19:26

Originally posted by aths
zecki, kannst du nicht einen aktivierbaren Alternativ-Modus einbauen, der auch beim Kern abbricht und erst mal weiter macht? ???

Bitte nochmal genauer, das habe ich jetzt nicht wirklich verstanden ;)

aths

2003-01-25, 17:20:52

Originally posted by zeckensack
???

Bitte nochmal genauer, das habe ich jetzt nicht wirklich verstanden ;) Wenn ein Rechteck nicht zustande kommst (da sich die Randfarbe ändert) brichst du das erst mal ab und machst weiter. Es müsste eine Möglichkeit geben zu verhindern, dass er schon im ersten Pass nach durchgehenden Kern-Linien sucht. Denn das kann ziemlich lange dauern, und man sieht praktisch noch nichts...

zeckensack

2003-01-25, 17:41:11

Originally posted by aths
Wenn ein Rechteck nicht zustande kommst (da sich die Randfarbe ändert) brichst du das erst mal ab und machst weiter. Es müsste eine Möglichkeit geben zu verhindern, dass er schon im ersten Pass nach durchgehenden Kern-Linien sucht. Denn das kann ziemlich lange dauern, und man sieht praktisch noch nichts... Hmmm.

Also ungefähr so:
Wenn Referenzfarbe==schwarz,null,nix
Dann erstmal was anderes machen
?

x-dragon

2003-01-25, 17:58:55

Irgendwie klappt das mit der vollen Präzision nicht mehr ganz:

zeckensack

2003-01-25, 18:07:41

Originally posted by X-Dragon
Irgendwie klappt das mit der vollen Präzision nicht mehr ganz: Ups!

Bestätigt, und Ursache gefunden.

turboschlumpf

2003-01-25, 18:08:51

^^
gleiches problem auch bei mir.
ab ungefähr e-014 bekomm ich nur noch klötzchen.

[edit] war ichmal wieder nicht schnell genug, grmpf :D

TheRealTentacle

2003-01-25, 18:37:36

Dein Webspace will nicht :(

Der T-online Webspace zeigt mir einen 404 Fehler

kann das jemand bestätigen?

/Edit: Problem ohne Grund nicht mehr vorhanden!

zeckensack

2003-01-25, 19:33:10

Fix (http://home.t-online.de/~zsack/brot.zip)

MeLLe

2003-01-25, 20:03:17

Märci.

aths

2003-01-25, 21:42:41

Komische Sache: In der Taskbar steht "done". Ich klicke das Ding an um das Fenster zu sehen - und er berechnet das Bild von Grund auf neu :madman:

zeckensack

2003-01-25, 22:16:52

Originally posted by aths
Komische Sache: In der Taskbar steht "done". Ich klicke das Ding an um das Fenster zu sehen - und er berechnet das Bild von Grund auf neu :madman: Ja :D
Das liegt daran, daß Minimieren/Maximieren als Größenänderung interpretiert wird. Und dann fängt er halt wieder von vorn an ?-)

(liegt an GLUT. Wo ist eigentlich Wuzel hin? =) )

MeLLe

2003-01-25, 22:20:12

Jetzt verstehe ich auch, warum der Effekt bei mir nicht auftrat - ich hab das Fenster zwar auch per Klick auf die Taskbar wieder reaktiviert, hatte es aber vorher nicht minimiert, sondern nur andere Fenster geöffnet, die "das Brot" überlagert haben. :)

aths

2003-01-26, 10:43:51

Originally posted by zeckensack
Ja :D
Das liegt daran, daß Minimieren/Maximieren als Größenänderung interpretiert wird. Und dann fängt er halt wieder von vorn an ?-)

(liegt an GLUT. Ausreden, alles Ausreden :naughty: :naughty: :naughty:
Prüfe doch nach jedem Resize, ob die Fenstergröße sich wirklich geändert hat und zeichne erst dann neu.

MeLLe

2003-01-26, 11:34:37

Einfacher wäre aber die Variante, dem Fenster die Minimier-/Maximier-Funktionalität zu nehmen.
Das aber nur if (strcmp(user_name,"aths")==0) ... *eg*

aths

2003-01-26, 14:35:57

Originally posted by MeLLe
Einfacher wäre aber die Variante, dem Fenster die Minimier-/Maximier-Funktionalität zu nehmen. "Deskop anzeigen" minimiert afaik alle Fenster.

MeLLe

2003-01-26, 16:48:23

Originally posted by aths
"Deskop anzeigen" minimiert afaik alle Fenster.
Grundsätzlich - ja. Hmpf, Krümelkacker ;-)
Allerdings sieht es manchmal so aus, als ob bestimmte Anwendungen nur "nicht angezeigt" und nicht wirklich minimiert werden. Hab jetzt kein wirkliches Beispiel, sonst könntest Du das selbst mal nachvollziehen.
Aber egal - back to Mandelbrot. ;)

turboschlumpf

2003-01-26, 17:20:00

aths, zeig uns doch mal ein paar schöne bilder.

mein pc rechnet sich zwar immer tot,
was anständiges kommt dabei aber nicht raus :D

aths

2003-01-26, 17:43:15

Originally posted by turboschlumpf
aths, zeig uns doch mal ein paar schöne bilder.

mein pc rechnet sich zwar immer tot,
was anständiges kommt dabei aber nicht raus :D Habe seit einiger Zeit keinen anständigen Zugriff auf meinen Webspace mehr (muss immer extra das Modem dafür anwerfen.)

Außerdem kostet son Bild gut und gerne schon mal 'ne halbe Stunde (und mehr!) Rechenzeit. Werde aber mal einige Sachen posten in den nächsten Tagen.

turboschlumpf

2003-01-26, 18:15:17

thx.
lass dir zeit.

Unregistered

2003-01-27, 02:05:18

hier mal ein bild.
http://badct.4players.de:1337/image.php?id=366

zeckensack

2003-01-27, 21:36:15

Wuff (http://home.t-online.de/~zsack/brot.zip)
Minimieren/Maximieren des Fensters beeinflußt jetzt nicht die Berechnung. Dh daß man das Brötchen endlich auch minimert im Hintergrund arbeiten lassen kann.
Speed-Optimierung der ExtremeFloats (8.5MFlop/s vs 4.8 MFlop/s auf meinem System). Leider numerisch etwas instabiler als vorher (rundet nicht mehr, fängt daher 'schon' ab ca e-47 an zu bröseln). Das geht noch besser, und wird irgendwann demnächst folgen

aths

2003-01-28, 01:15:39

Genial!

edit: Protest! Ist das AA oder doch eher nur Quincunx?

edit2: Das ist ein reiner Blur! Buaahhh... *Würg*. Echtes AA wäre mir lieber.

edit3: Ich nehme alles zurück und behaupte das Gegenteil! Ich hatte in OpenGL 4x 9-tap Multisampling aktiviert...

edit4: FSAA hätte ich trotzdem gerne! :D

Kennung Eins

2003-01-28, 13:06:39

@Zeckensack

wäre es möglich, in irgendeiner Form dem Programm einen zu laufenden Pfad vorzugeben?

Also irgendwie als Parameter an das Programm die "Zielkoordinaten" übergeben, damit man nicht ständig ins Bild klicken muss.
Dann kann das meinetwegen den ganzen Tag rechnen, und wenn ich abends von der Uni komme, hab ich ein fertig berechnetes Bild :)

Ich lesen diesen Thread schon seit einiger Zeit und kann dazu eigendlich nur eins sagen:
Wooooooooooooooooooooooooooowwww.....

Originally posted by aths
Genial!

edit: Protest! Ist das AA oder doch eher nur Quincunx?

edit2: Das ist ein reiner Blur! Buaahhh... *Würg*. Echtes AA wäre mir lieber.

edit3: Ich nehme alles zurück und behaupte das Gegenteil! Ich hatte in OpenGL 4x 9-tap Multisampling aktiviert...

edit4: FSAA hätte ich trotzdem gerne! :D LOL!

aths

2003-01-28, 22:31:17

zecki, ich finde die Bildauffrischrate könnte etwas niedriger sein. Der aktualisiert mir zu oft :)

btw, hier mal ein paar Bilder (mit rainbow.pal)

http://www.aths.net/files/mandel1.jpg

http://www.aths.net/files/mandel2.jpg

http://www.aths.net/files/mandel3.jpg

http://www.aths.net/files/mandel4.jpg

http://www.aths.net/files/mandel5.jpg

Xmas

2003-01-28, 23:47:47

Kann man die Palettendatei auch als Parameter an das Programm übergeben? Wäre ganz praktisch, wenn man einfach nur die Palette auf Brot.exe ziehen muss.

Mr. Tweety

2003-01-29, 13:16:10

Also irgendwas mach ich verkehrt.

Ich click und click und er rechnet wie ein blöder aber ich bekomm nicht mal ansatzweise solche bilder zusammen ?-)

turboschlumpf

2003-01-29, 13:26:31

jo, ist bei mir genauso.

die bilder sind ja geil!!
vor allem das vorletzte.

Mr. Tweety

2003-01-29, 14:17:20

Jo die verheimlichen uns bestimmt irgendwas ;)

zeckensack

2003-01-29, 16:44:17

Arf arf arf! (http://home.t-online.de/~zsack/brot.zip)
Navigation geht jetzt auch mit den Pfeiltasten. PageUp/PageDown zoomen zentriert, SHIFT erhöht wie gehabt den Zoomfaktor.
Langsameres Update bei double precision. Ich hatte das zwar ausgemessen, aber Mist gemessen :) (thx für Hinweis @ aths)
Presets! Die Datei 'places' im Programmverzeichnis speichert zwölf Presets, die mit den F-Tasten abrufbar sind. CTRL+F* speichert die aktuelle Ansicht zum späteren Abruf (bzw Austausch mit anderen, Hint @ aths :naughty: ). Ich liefere einen Satz Presets dazu, es gibt aber bestimmt schönere Ecken im Fraktal, also immer her damit.
Auf XMas' Wunsch kann als erster Parameter jetzt eine Paletten-Datei übergeben werden. Das ganze verhält sich reichlich merkwürdig, weil beim 'Draufziehen' einer Palette auf Brot.exe die Presets nicht gefunden werden (respektive bei mir in C:\places gesucht und später gespeichert werden :| )
ExtremeFloat-Multiplikation und -Addition beherrschen jetzt korrektes 'round to nearest'. Subtraktion ist leider viel komplizierter als ich befürchtet hatte ...
Die erreichte Präzision sollte jetzt aber wieder etwas besser sein.

zeckensack

2003-01-29, 16:46:55

Originally posted by Kennung Eins
@Zeckensack

wäre es möglich, in irgendeiner Form dem Programm einen zu laufenden Pfad vorzugeben?

Also irgendwie als Parameter an das Programm die "Zielkoordinaten" übergeben, damit man nicht ständig ins Bild klicken muss.
Dann kann das meinetwegen den ganzen Tag rechnen, und wenn ich abends von der Uni komme, hab ich ein fertig berechnetes Bild :)I woass net ?-)
Was meinst du mit Pfad?
Du mußt schon selbst die richtige Stelle anklicken, intelligente Mustererkennung und automatische Auswahl des 'schicksten' Bereichs übersteigen meine Möglichkeiten doch bei weitem.

Lost Prophet

2003-01-29, 17:27:51

ok, ich bin brot-neuling, aber

WO FINDET IHR ALL DIE GEILEN STELLEN!?!?!?!?!?!

bitte tips zum professionellen mandelbrotmengen-surfen (:D)

danke

cya axel

zeckensack

2003-01-29, 17:36:56

Originally posted by Purple_Stain
ok, ich bin brot-neuling, aber

WO FINDET IHR ALL DIE GEILEN STELLEN!?!?!?!?!?!

bitte tips zum professionellen mandelbrotmengen-surfen (:D)

danke

cya axel Keine Ahnung. Ist oft auch eine Frage der richtigen Palette, ob ein Bild geil oder muh aussieht.

Wenn aths mal ein paar Presets rausrückt, kannst du mittels PageDown rauszoomen, um zu sehen wo das ganze gefunden wurde :)
Das alte Bild bleibt dabei ganz genau in der Mitte hängen, ist ganz gut für den Überblick. Das ist auch der eigentliche Grund, warum ich das so implementiert habe ;)

aths

2003-01-29, 17:43:52

Leider noch mit der alten Version gemacht :naughty:

http://www.aths.net/files/mandel6.jpg

http://www.aths.net/files/mandel7.jpg

http://www.aths.net/files/mandel8.jpg

http://www.aths.net/files/mandel9.jpg

http://www.aths.net/files/mandel10.jpg

Ich hab noch 5 weitere Bilder, allerdings ebenfalls ohne Presets...

Kennung Eins

2003-01-29, 18:54:11

boah, bei den Bildern krieg ich ja angst, aths!!
sieht ja krass aus...

Originally posted by zeckensack
I woass net ?-)
Was meinst du mit Pfad?
Du mußt schon selbst die richtige Stelle anklicken, intelligente Mustererkennung und automatische Auswahl des 'schicksten' Bereichs übersteigen meine Möglichkeiten doch bei weitem. :) Ich meine mit "Pfad" sozusagen "den Weg des Klickens".

Also daß der aufzeichnet, wo man hinklickt, das dann in eine Datei speichert, und diese Datei dann irgendwie abrufbar ist.
So daß jeder an die selbe Stelle geführt werden kann.

Du hast ja schon die vielen Fragen der Art "ich klick hier die ganze Zeit rum, finde aber keine solchen geilen stellen, wo muß ich also wie oft hinklicken?" gelesen. Eben sowas meine ich mit "Pfad".

zeckensack

2003-01-29, 19:09:41

Originally posted by Kennung Eins
boah, bei den Bildern krieg ich ja angst, aths!!
sieht ja krass aus...

:) Ich meine mit "Pfad" sozusagen "den Weg des Klickens".

Also daß der aufzeichnet, wo man hinklickt, das dann in eine Datei speichert, und diese Datei dann irgendwie abrufbar ist.
So daß jeder an die selbe Stelle geführt werden kann.

Du hast ja schon die vielen Fragen der Art "ich klick hier die ganze Zeit rum, finde aber keine solchen geilen stellen, wo muß ich also wie oft hinklicken?" gelesen. Eben sowas meine ich mit "Pfad". Aaaah so :)

Das wird sich hoffentlich mit dem Speichern von Presets erledigt haben ;)
Jemand, der die 'geilen Stellen' kennt, kann bis zu zwölf davon speichern, und die entsprechende Datei weitergeben.
Dann brauchst du nur die Datei bei dir ins Verzeichnis werden, auf die F-Tasten hacken, und rauszoomen, dann weißt du wo's langgeht =)

Kannst es ja mal mit den mitgelieferten probieren, die sind halt zugegeben nicht besonders spektakulär, aber das Verfahren ist ja das gleiche.

Kennung Eins

2003-01-29, 19:21:53

Originally posted by zeckensack
Aaaah so :)

Das wird sich hoffentlich mit dem Speichern von Presets erledigt haben ;)
Jemand, der die 'geilen Stellen' kennt, kann bis zu zwölf davon speichern, und die entsprechende Datei weitergeben.
Dann brauchst du nur die Datei bei dir ins Verzeichnis werden, auf die F-Tasten hacken, und rauszoomen, dann weißt du wo's langgeht =)

Kannst es ja mal mit den mitgelieferten probieren, die sind halt zugegeben nicht besonders spektakulär, aber das Verfahren ist ja das gleiche. jaaaa!
genau das wollte ich sehen :D kuhl, thx

Lost Prophet

2003-01-29, 19:33:04

@aths

extrem geile bilder

@z-bag

naja ok =)

das mit den paletten lass ich derweil noch mal
schau mir lieber deine presets an

bin grad bei nr 6 und mein 1400 MHz Athlon muss da schon seit mehr als 1ner stunde arbeiten (und immer noch in der vorletzten "schicht" :...( )

das war eben das schöne an der "alten" version da hab ich mir wenigstens schon Teile des bildes ansehn können aber so ;)

achja ich bin in 1280x1024 unterwegs :D (das macht was aus oder ;D)

cya axel

zeckensack

2003-01-29, 19:37:00

@athsOriginally posted by zeckensack
Auf XMas' Wunsch kann als erster Parameter jetzt eine Paletten-Datei übergeben werden. Das ganze verhält sich reichlich merkwürdig, weil beim 'Draufziehen' einer Palette auf Brot.exe die Presets nicht gefunden werden (respektive bei mir in C:\places gesucht und später gespeichert werden :| )
Hast du das Problem auch?
Wenn ich in einer DOS-Box zB "brot rainbow.pal" eingebe, dann funzt's, wenn ich rainbow.pal dagegen auf brot.exe draufziehe, dann nicht. Könnte fast an Windows98 liegen ... wäre mein erstes echtes Problem mit diesem OS :|

Ich frage deshalb, weil wir von dir ja in Kürze großartige Presets haben wollen :D

Ich bin mir auch über die Roadmap nicht im klaren. Subtraktion muß korrekt runden, das wäre klar. Aber beim AA habe ich grooooße Sorgen. Ich würde gern wenn schon dann gleich Sparse Supersampling einpflanzen, nur das verträgt sich IMO nicht mit der Rechtecks-Teilung und killt mir ganz allgemein die Optimierung.

Also OGSS? Igitt ...

zeckensack

2003-01-29, 19:38:24

Originally posted by Purple_Stain
achja ich bin in 1280x1024 unterwegs :D (das macht was aus oder ;D)

cya axel Ja natürlich macht das was aus! :bad1:

Versuch's halt mal etwas bescheidener ;)

aths

2003-01-29, 19:45:29

Originally posted by zeckensack
@athsHast du das Problem auch?
Wenn ich in einer DOS-Box zB "brot rainbow.pal" eingebe, dann funzt's, wenn ich rainbow.pal dagegen auf brot.exe draufziehe, dann nicht. Könnte fast an Windows98 liegen ... wäre mein erstes echtes Problem mit diesem OS :|Bei mir (WinXP Home OEM, aber original!! :naughty: ) klappts problemlos. Aber so wie es jetzt ist, ist es witzlos. Ich möchte gerne nachträglich Bilder umfärben können!Originally posted by zeckensack
Aber beim AA habe ich grooooße Sorgen. Ich würde gern wenn schon dann gleich Sparse Supersampling einpflanzen, nur das verträgt sich IMO nicht mit der Rechtecks-Teilung und killt mir ganz allgemein die Optimierung.

Also OGSS? Igitt ... Beim Mandelbrot ist OGSS gar nicht mal so nachteilhaft. Es geht weniger darum, Kanten zu glätten (da man ohnehin lieber Paletten nehmen sollte, die sanfte Farbübergänge haben) sondern vor allem darum, im "Gegrissel" noch so gut es geht Strukturen ausmachen zu können.

AA stelle ich mir so vor :) Man drückt z.B. "A" wenn das Bild fertig ist, und er nimmt das bekannte Material und verfeinert es um Faktor 2x2. (Am besten wäre, wenn man anschließend noch mal "A" drücken könnte, für insgesamt 4x4 AA.)

Idee: "Multisampling" *auf Wunsch*. Wenn im Originalbild ein Pixel in seiner 8-er Umgebung nur von gleichfarbigen Pixeln umgeben ist, wird er nicht höher aufgelöst. "Multisampling" versagt bei dünnen "Ritzen" und sollte daher immer optional sein. Wichtiger wäre erst mal Supersampling. Meinetwegen auch RG, in dem du einfach noch mal das gesamte Bild mit Subpixel-Shifting renderst und die Buffer dann vermischst.

Oder wie auch immer :)

Xmas

2003-01-29, 19:53:46

Lost Prophet

2003-01-29, 19:54:51

Originally posted by zeckensack
Ja natürlich macht das was aus! :bad1:

Versuch's halt mal etwas bescheidener ;)

nicht haun! oder hast du den smiley übersehn??? (hab ich eh gewusst =))

will ich aber nicht, ich brauch die volle schönheit :naughty:

cya axel

Kennung Eins

2003-01-29, 20:34:38

grml... der rechnet grad fast ne Stunde an einem Bild, und ich blödmann öffne ICQ, welches ich in an der rechten Bildschirmseite angedockt habe. Toll.
Das angedockte ICQ verkleinert den Windows-Fullscreen-Bereich, so daß alle Fenster, die das ICQ-Fenster überdecken würden, automatisch verkleinert werden.

Und futsch ist mein Bild, er fängt wieder von vorne an zu rechnen ... grrrr....

Zecki,
lässt sich dagegen irgendwas machen?

Lost Prophet

2003-01-29, 20:46:46

und wenn du am ende bist..... benützte die "Q"-taste und erlebe das wunder

oh mann ich hab ein neues spielzeug :O

mein comp schwitzt die ganze zeit ;D

und wichtig

g00t ding braucht weile :D

cya axel

edit:

@ zecki:

hast du soundzugriff??
ich bräucht nämlich nen wecker wenn ein Bild fertig ist (ist ernst gemeint)

Kennung Eins

2003-01-29, 20:58:12

...und ne Pause-Funktion wär geil!

Sonst kann ich ein paar Minuten warten, bevor irgendwelche Anwendungen starten, wenn ich "rechnen lasse" :)

2003-01-29, 20:59:25

aths

2003-01-29, 21:05:20

Originally posted by Kennung Eins
...und ne Pause-Funktion wär geil!

Sonst kann ich ein paar Minuten warten, bevor irgendwelche Anwendungen starten, wenn ich "rechnen lasse" :) Priorität verringern.

Lost Prophet

2003-01-29, 22:09:11

zecki, ich will ja deine (noch-für-mandelbrotrenderer-)TO-DO-LIST nicht sprengen

aber du hast selbst gesagt

in der eine palette schauts geil aus in einer anderen shice

also wie wärs mit funktionstasten für jede palette???

:naughty:

cya axel

Kennung Eins

2003-01-29, 22:27:54

Juhu :)

http://www.uni-magdeburg.de/tuemler/1.77e-015.jpg

Zeckensack, das funktioniert echt wunderbar.

Unregistered

2003-01-30, 02:16:29

hm vielleicht schaff ich das jetzt auch mal dass das bild gleich erscheint
<img src='www.badct.de/image.php?id=367>

Unregistered

2003-01-30, 02:17:38

<img src='http://www.badct.de/image.php?id=367>

http://www.badct.de/image.php?id=367

Unregistered

2003-01-30, 02:18:00

was mach ich denn falsch?????????????

Xmas

2003-01-30, 02:37:15

[IMG] URL [/IMG ] (ohne Leerzeichen)
Keine spitzen Klammern, HTML funktioniert hier nicht :)

Unregistered

2003-01-30, 09:23:36

naja der linkg der oben einegfügt wurde hab ich mit [url] gemacht. ka warum das bild nicht gelich angezeigt wird. ist ja auch egal. das bild hat der zecke ja schon in seiner vorbelegung drin geahbt. habs nur ned gesehen, da ich noch die alte version benutzt habe :)

aths

2003-01-30, 13:39:03

http://www.aths.net/files/mandel11.jpg

http://www.aths.net/files/mandel12.jpg

http://www.aths.net/files/mandel13.jpg

http://www.aths.net/files/mandel14.jpg

http://www.aths.net/files/mandel15.jpg

Die Bilder sind sehr groß (von der Dateigröße her) aber haben wegen der Komprimierung bei weitem nicht die Brillianz wie unkomprimiert :(

aths

2003-01-30, 13:52:28

zecki, ist da performance-mäßig noch was drin? Z.B. dass zunächst nur mal 128 Bit Floats genommen werden? Auch wäre eine Fortschritts-Anzeige ("40.42%") in der Titlebar nützlich. Wenn das Bild fertig ist, wäre auch im Text-Fenster eine Meldung ganz interessant, wieviele Pixel dank Optimierung nicht berechnet wurden (am besten noch mal aufgesplittet in Farb- und Kern-Pixel.)

Ein Klick-Schutz wäre ebenfalls nett. (Per Tastendruck die Entgegenahme von Mausklicks sperren und wieder aufheben. Ich ziele beim Klicken auf Windows Fenster-Elemente manchmal etwas ungenau, und dann ist der Ärger groß...)

zeckensack

2003-01-30, 14:01:07

Originally posted by aths
zecki, ist da performance-mäßig noch was drin? Z.B. dass zunächst nur mal 128 Bit Floats genommen werden? Auch wäre eine Fortschritts-Anzeige ("40.42%") in der Titlebar ganz nützlich. Ich habe gestern abend noch angefangen, Contour Tracing einzubasteln. Da habe ich im Moment aber noch ein paar Probleme.
Wenn das fertig wird, ist es zumindest für schwierige Bilder (hohe mittlere Iterationstiefen und/oder ExtremeFloats) wesentlich flotter als das Rechtecks-Dingsbums.

Fortschritts-Anzeigen wird es eher nicht geben. Der Renderer 'weiß' überhaupt nicht wie weit er schon ist :)
Das einzige was er feststellen kann, ist ob das Bild fertig ist.

Das Ding hat ja quasi eine 'To do-List', diese verändert aber unvorhersehbar ihre Größe. Fertig ist's genau dann, wenn diese leer ist.

zeckensack

2003-01-30, 14:02:45

Originally posted by aths
Ein Klick-Schutz wäre ebenfalls nett. (Per Tastendruck die Entgegenahme von Mausklicks sperren und wieder aufheben. Ich ziele beim Klicken auf Windows Fenster-Elemente manchmal etwas ungenau, und dann ist der Ärger groß...) Oh Mann ... :stareup:

Naja, ich werd' mal sehen was ich für dich tun kann ;)

aths

2003-01-30, 14:41:15

Originally posted by zeckensack
Fortschritts-Anzeigen wird es eher nicht geben. Der Renderer 'weiß' überhaupt nicht wie weit er schon ist :)
Das einzige was er feststellen kann, ist ob das Bild fertig ist.Doch - du könntest einfach jeden gemalten Pixel mit einer globalen Variable mitzählen :)

Lost Prophet

2003-01-30, 16:07:54

Hab gestern meinen prozzi schön schuften lassen, und ein paar presets gespeichert

(nicht in def.pal)

und die sind heute futsch!

was hab ich falsch gemacht?

cya axel

zeckensack

2003-01-30, 17:42:02

Originally posted by Purple_Stain
Hab gestern meinen prozzi schön schuften lassen, und ein paar presets gespeichert

(nicht in def.pal)

und die sind heute futsch!

was hab ich falsch gemacht?

cya axel Such mal nach einer Datei namens 'places'. Wenn man eine Palette auf Brot.exe draufzieht, dann wird die nicht im Programmverzeichnis gespeichert, sondern in C:\ (Win98) oder irgendwo in 'Eigene Dateien' (Win2k/XP). Du kannst die Datei ins Programmverzeichnis zurückkopieren (bei Bedarf ein Backup von der dort schon vorhandenen Datei machen), oder einfach nochmal das Programm durch Draufziehen einer Palette starten. Dann müßte er's an der gleichen (falschen) Stelle wieder finden.

Ich weiß im Moment nicht, was ich gegen diesen ärgerlichen Bug machen kann, denn es liegt IMO an Windows' Verständnis von 'Arbeitsverzeichnis' und nicht an meiner Programmlogik. XMas hat ja schon den Workaround mit der Verknüpfung beschrieben.

aths

2003-01-30, 18:35:20

Du kannst doch das Verzeichnis aus einer INI-Datei auslesen. Ist zwar etwas umständlich, wenn das Programm durch Spielerei an einer INI (und dem wahlweisen Anlegen eines extra Verzeichnisses) "installiert" werden muss, dafür wäre es dann "sicher".

zeckensack

2003-01-30, 19:18:09

Originally posted by aths
Du kannst doch das Verzeichnis aus einer INI-Datei auslesen. Ist zwar etwas umständlich, wenn das Programm durch Spielerei an einer INI (und dem wahlweisen Anlegen eines extra Verzeichnisses) "installiert" werden muss, dafür wäre es dann "sicher". Wenn ich so darüber nachdenke, geht es auch anders :)

Erste Maßnahme:
Auslesen des Programmpfads (Parameter 0, ist zB bei mir D:\proj\Brot\Release\brot.exe), und entsprechende Anpassung der statischen Dateioperationen ('places').

Zweite Maßnahme:
Dynamische Dateioperationen (Paletten) mit einem Windows-Dialog lösen. Kommandozeilenparameter um den Programmpfad ergänzen wenn sie nicht schon selbst einen Pfad enthalten.

aths

2003-01-30, 20:19:28

Ehrlich gesagt halte ich FSAA für wichtiger als Fragen rund um das Paletten-Managment. Ich habe def.pal ohnehin ersetzt :)

Lost Prophet

2003-01-30, 22:42:52

tschuldigung das ich soviel zu kritisieren hab, sollen aber mehr konstrukive vorschläge sein

folgende situation

ich Zoome irgenwo hinein, in eine "kreuzung" und geh immer wieter bis zu deren kern vor

wenn mir dann zu viel schwarz ist und ich die iterationsstufe höher stelle dann berechnet er das ganze bild nochmal (=zeitverlust)

kann man da was machen

(das mit der globalen variable (aths) müsste doch da gehn oder ?? :|)

cya axel

aths

2003-01-31, 01:57:44

Originally posted by Purple_Stain
ich Zoome irgenwo hinein, in eine "kreuzung" und geh immer wieter bis zu deren kern vor

wenn mir dann zu viel schwarz ist und ich die iterationsstufe höher stelle dann berechnet er das ganze bild nochmal (=zeitverlust)Bei mir berechnet er nur den Kern noch mal neu, was ansonsten an Farbe schon da ist, bleibt.

Xmas

2003-01-31, 02:08:52

Originally posted by aths
Bei mir berechnet er nur den Kern noch mal neu, was ansonsten an Farbe schon da ist, bleibt.
Ja es bleibt, es dauert aber trotzdem ewig selbst wenn nur eine winzige Fläche schwarz ist. Und dem Aufbau nach zu urteilen wird das ganze Bild wieder durchlaufen.

Xmas

2003-01-31, 02:12:27

Originally posted by Unregistered
naja der linkg der oben einegfügt wurde hab ich mit [url] gemacht. ka warum das bild nicht gelich angezeigt wird.
Hab ich doch geschrieben. Wenn das Bild angezeigt werden soll, musst du [IMG]-Tags verwenden, nicht [URL].

zeckensack

2003-01-31, 13:52:55

Originally posted by Purple_Stain
tschuldigung das ich soviel zu kritisieren hab, sollen aber mehr konstrukive vorschläge sein

folgende situation

ich Zoome irgenwo hinein, in eine "kreuzung" und geh immer wieter bis zu deren kern vor

wenn mir dann zu viel schwarz ist und ich die iterationsstufe höher stelle dann berechnet er das ganze bild nochmal (=zeitverlust)

kann man da was machen

(das mit der globalen variable (aths) müsste doch da gehn oder ?? :|)

cya axel Wenn du die Iterationstiefe verringerst, dann rechnet er alles neu. Beim Erhöhen werden nur die schwarzen Stellen wirklich neu berechnet.

zeckensack

2003-01-31, 13:59:49

Originally posted by Xmas

Ja es bleibt, es dauert aber trotzdem ewig selbst wenn nur eine winzige Fläche schwarz ist. Und dem Aufbau nach zu urteilen wird das ganze Bild wieder durchlaufen. Der Bildaufbau fängt wieder von vorne an - zwecks sauberem Kacheln ist das der Weg des geringsten Widerstands.

Jede Farbberechnung läuft aber über eine Art Cache. Farben, die bereits mindestens einmal abgefragt wurden, werden nicht mehr durch Iteration bestimmt, sondern einfach aus dem fertigen Bild geholt. Dh daß nie mehr als eine 'richtige' Berechnung pro Pixel erfolgt.

Beim Erhöhen der Iterationstiefe passiert nun dies hier:
if (max_it>this->max_it)
{
reset_nondestructive();
for (uint y=0;y<height;++y)
for (uint x=0;x<width;++x)
if (image_data[y*width+x]==0) valid->clear(x,y);
}

Der 'Cache' wird nur an den schwarzen Stellen zurückgesetzt. Dadurch werden die fertigen Pixel, die nicht am Iterationslimit gescheitert sind (=> nicht schwarz sind) im nicht neu berechnet.

Sie werden zwar weiter von der Mustererkennung abgefragt, aber eben nicht mehr durchgerechnet.

Jetzt klarer? :)

zeckensack

2003-01-31, 14:03:06

Btw, die Rechteckserkennung ist fürcherlich ineffizient und wird desöfteren sogar vom Brute-Force Durchrechnen des Bilds geschlagen :eyes:

Deswegen: Erstmal contour tracing, erst dann lohnt sich AA. Das wird nun übrigens doch sparse supersampling, ich habe einen Weg gefunden ...

Unregistered

2003-01-31, 14:20:20

Originally posted by Xmas

Hab ich doch geschrieben. Wenn das Bild angezeigt werden soll, musst du [IMG]-Tags verwenden, nicht [URL].

hab mich vertippt meinte [IMG]

villeicht soltle ich mich regstireioren :) könnte ja abhilfe schaffen

Lost Prophet

2003-01-31, 14:45:42

Originally posted by zeckensack
Der Bildaufbau fängt wieder von vorne an - zwecks sauberem Kacheln ist das der Weg des geringsten Widerstands.

Jede Farbberechnung läuft aber über eine Art Cache. Farben, die bereits mindestens einmal abgefragt wurden, werden nicht mehr durch Iteration bestimmt, sondern einfach aus dem fertigen Bild geholt. Dh daß nie mehr als eine 'richtige' Berechnung pro Pixel erfolgt.

Beim Erhöhen der Iterationstiefe passiert nun dies hier:
if (max_it>this->max_it)
{
reset_nondestructive();
for (uint y=0;y<height;++y)
for (uint x=0;x<width;++x)
if (image_data[y*width+x]==0) valid->clear(x,y);
}

Der 'Cache' wird nur an den schwarzen Stellen zurückgesetzt. Dadurch werden die fertigen Pixel, die nicht am Iterationslimit gescheitert sind (=> nicht schwarz sind) im nicht neu berechnet.

Sie werden zwar weiter von der Mustererkennung abgefragt, aber eben nicht mehr durchgerechnet.

Jetzt klarer? :)

ja danke =)

cya axel

(die mustererkennung schlug mir ein schnippchen) ;)

aths

2003-01-31, 16:22:53

Originally posted by zeckensack
Btw, die Rechteckserkennung ist fürcherlich ineffizient und wird desöfteren sogar vom Brute-Force Durchrechnen des Bilds geschlagen :eyes: Hm? Das kann doch gar nicht sein?

zeckensack

2003-02-01, 12:39:48

Originally posted by aths
Hm? Das kann doch gar nicht sein? War ein Bug in der Cache-Logik :sulkoff:

Trotzdem zieht Contour Tracing der Rechteckserkennung die Hosen aus. Mehr in Kürze.

zeckensack

2003-02-01, 13:31:33

Das ist ja richtig anstrengend ... (http://home.t-online.de/~zsack/brot.zip)
Contour tracing => speeeeeed! :saiyan:
Bugfix für den Cache (siehe oben) => noch mehr speeed! :karate:
Bugfix: Iterationstiefe von genau 1 führt nicht mehr zum 'Umdrehen' des Fraktals.
Workaround: 'places' wird jetzt immer aus dem gleichen Verzeichnis geladen, in dem sich auch Brot.exe befindet. Ab jetzt also endlich Paletten-Draufziehen ohne Reue :)
Mouse-Lock (auf aths' Anfrage). L drücken =)
Die Tasten W und S ändern jetzt auch die Iterationstiefe, aber in kleineren Schritten als Q/A
Preview ist wieder drin
'Effizienz'-Anzeige. 100% (die unmöglich erreicht werden können, btw) bedeutet, daß kein Sample wirklich ausgerechnet wurde. Umgekehrt bedeutet 0%, daß alle Samples durchgerechnet wurden. 50% bedeutet sinngemäß, daß 50% der Samples 'normal' erzeugt wurden, und die restlichen 50% 'geraten' sind. In Kurzform ist diese Zahl also die Wirksamkeit der angewandten Optimierung.

Todo: Rundung bei Subtraktion (immer noch ...)
Palette bei laufendem Programm wechseln (Windows-Dialog)
Sparse Supersampling

aths

2003-02-01, 13:36:44

Ähm. Mit welchen Mitteln berechnest du das Vorschau-Bild? (Mit Optimierungen?)

Optimierst du anschließend im Kern was weg?

zeckensack

2003-02-01, 13:45:10

Originally posted by aths
Ähm. Mit welchen Mitteln berechnest du das Vorschau-Bild? (Mit Optimierungen?)Nope.
1)Contour Tracing führt zu Fehlern, wenn man Samples wegläßt.
2)Der momentan implementierte Algorithmus terminiert nur dann sauber, wenn er lückenlos von oben links nach unten laufen darf. Aufhänger will ich nicht für's Preview riskieren.
Deswegen ist das Preview jetzt Brute Force. Im Schnitt werden ca 1,5% aller Samples vom Preview ausgerechnet. Ich hielt das für einen brauchbaren Kompromiß, zumal die Samples nicht verworfen werden.

Optimierst du anschließend im Kern was weg? Jein :)
Der schwarze Kern wird als Kontur erkannt und sein kompletter Rand wird abgefahren. Das halte ich aber nicht für schlimm, denn ob ich jetzt 'von innen' einen schwarzen Rand ziehe, oder 'von außen' einen Übergang zu schwarz erkenne, macht für den gesamten Rechenaufwand keinen Unterschied.
Nach gleicher Logik macht es auch keinen Unterschied, wenn ich mir den Kern bis zum Schluß aufhebe. Dann wären nämlich sowieso alle Ränder des Kerns bereits durchgerechnet (bei der Prüfung der angrenzenden Strukturen).

aths

2003-02-01, 13:54:47

Originally posted by zeckensack
Jein :)
Der schwarze Kern wird als Kontur erkannt und sein kompletter Rand wird abgefahren. Das halte ich aber nicht für schlimm, denn ob ich jetzt 'von innen' einen schwarzen Rand ziehe, oder 'von außen' einen Übergang zu schwarz erkenne, macht für den gesamten Rechenaufwand keinen Unterschied.
Nach gleicher Logik macht es auch keinen Unterschied, wenn ich mir den Kern bis zum Schluß aufhebe. Dann wären nämlich sowieso alle Ränder des Kerns bereits durchgerechnet (bei der Prüfung der angrenzenden Strukturen). Das ist Shice. Begründung folgt.

edit: Also, grrr, beim Kern darf man nur so optimieren: Rechteck-Methode und echtes, komplettes Boundary Tracing. Jedes "Solid guessing" (letztlich machst du das, wenn ich das richtig verstehe) kann zu Fehlern führen. Das Problem sind die "Ritzen", also die Kreise an den Kreisen... einige "Ritzen" erscheinen hier komplett "spitz", andere Ritzen sind "stumpf". Das Vorschaubild ist ja eine gröbere Auflösung des Bildes, da kann es schon mal passieren, dass eine dünne Spalte übersehen wird weil diese unerkannt in den Kern reicht, dann aber wegoptimiert wird.

Warum berechnest du das Vorschaubild nicht mit der Rechteck-Methode? Im Kern sollte man sparen, und das Ding ist (für die Auflösung der Vorschau) absolut sicher.

Ansonsten danke ich erst mal für den hervorragenden Speed-Up!!

edit2: Du solltest was einbauen, um das "Keine Rückmeldung"-Problem zu umgehen. Z.B. wenn man gerade im Kern ist, stur alle 10 Pixel wieder mal eine Tastatur- bzw. Mausabfrage entgegen nehmen. Das verlangsamt die Sache sicherlich, aber verbessert imo das Handling.

aths

2003-02-01, 14:24:03

Beispiel:

Die Ritze oben ist ok, die unten seltsam abgeschnitten. Wenn man Itermax erhöht, scheint die Optimierung nicht mehr zu greifen, und dann sind beide ok. Bislang sah ich solche Artefakte in deinem Prog aber nicht, nun fallen sie mir laufend auf...

zeckensack

2003-02-01, 14:24:07

Originally posted by aths
echtes, komplettes Boundary Tracing.Genau das habe ich eingebaut. Was meinst du, warum das so lange gedauert hat? :)
Der Algo wird nur auf Samples angewandt, die mindestens einen gleichfarbigen Nachbarn haben.
Ansonsten erkennt das Ding alles, inklusive Regionen von 1x2 oder 2x1 gleichfarbigen.

Ausnahme:
----
-x--
-x--
--x-
----
Geht nicht. Der Algo schaut nicht 'um Ecken'. Das wird also als 1x2-Region und ein einzelner Pixel erkannt, was aber natürlich nicht falsch ist.

Jedes "Solid guessing" (letztlich machst du das, wenn ich das richtig verstehe) kann zu Fehlern führen. Das Problem sind die "Ritzen", also die Kreise an den Kreisen... einige "Ritzen" erscheinen hier komplett "spitz", andere Ritzen sind "stumpf". Das Vorschaubild ist ja eine gröbere Auflösung des Bildes, da kann es schon mal passieren, dass eine dünne Spalte übersehen wird weil diese unerkannt in den Kern reicht, dann aber wegoptimiert wird.IMO kann das nicht passieren. Aber ich könnte mich natürlich irren. Hast du fehlerhafte Bilder bekommen?

Warum berechnest du das Vorschaubild nicht mit der Rechteck-Methode? Im Kern sollte man sparen, und das Ding ist (für die Auflösung der Vorschau) absolut sicher.Die Rechteckmethode kann in schwarzen Regionen genausowenig punkten wie die aktuelle. Um festzustellen, daß ein Sample schwarz ist, muß ich's schließlich erstmal durchrechnen. Um ein komplettes Rechteck als schwarz durchgehen zu lassen, müssen alle Randsamples durchgerechnet und für schwarz befunden werden. Das ist definitiv nicht schneller, als ein einzelnes Sample aus der Mitte zu nehmen und es gut sein lassen.

Ansonsten danke ich erst mal für den hervorragenden Speed-Up!!Na wenigstens etwas positives :naughty:

:)

aths

2003-02-01, 14:31:45

Mehr zur "Optimierung":

Solche "Hüggel", die alle zufällig Rechteck-Form aufweisen, gabs bislang nicht.

zeckensack

2003-02-01, 14:33:01

Originally posted by aths
edit2: Du solltest was einbauen, um das "Keine Rückmeldung"-Problem zu umgehen. Z.B. wenn man gerade im Kern ist, stur alle 10 Pixel wieder mal eine Tastatur- bzw. Mausabfrage entgegen nehmen. Das verlangsamt die Sache sicherlich, aber verbessert imo das Handling. Kann ich gut verstehen :D
Dann wird's aber so langsam unübersichtlich ... schaumer mal ;)

aths

2003-02-01, 14:35:49

Originally posted by zeckensack
IMO kann das nicht passieren. Aber ich könnte mich natürlich irren. Hast du fehlerhafte Bilder bekommen?Japp. Mein feinnerviges Sehorgan ist ganz geschockt.
Originally posted by zeckensack
Die Rechteckmethode kann in schwarzen Regionen genausowenig punkten wie die aktuelle. Um festzustellen, daß ein Sample schwarz ist, muß ich's schließlich erstmal durchrechnen. Um ein komplettes Rechteck als schwarz durchgehen zu lassen, müssen alle Randsamples durchgerechnet und für schwarz befunden werden. Das ist definitiv nicht schneller, als ein einzelnes Sample aus der Mitte zu nehmen und es gut sein lassen.Das Vorschau-Bild ist ja das Bild in geringerer Auflösung. Mit Rechtecken muss schlimmstenfalls jedes Pixel berechnet werden. Ohne Rechtecke muss immer jedes Pixel berechnet werden. Rechtecke können "inneres" aber mit Blockfill u.U. schneller erledigen, wenn der komplette Rand schwarz ist. Die 1,5% Pixel kannste dann auch wegschmeißen und das echte Bild komplett neu berechnen. Ansonsten müsstest du passgenaue Subpixel-Rechnungen betreiben.

Zur Optimierung noch mal: Den Fehler könnte man verringern, wenn auf eine 3x3-Umgebung o.ä. geprüft würde (und alles was in der Vorschau-3x3-Umgebung nicht komplett schwarz ist, wird als Rand aufgefasst.) Doch alle solche "guessing"-Optimierungen bleiben letztlich immer unsauber.

zeckensack

2003-02-01, 14:39:39

Kann ich nicht nachvollziehen :|

Es kann sein, daß du nicht die angekündigte Version, sondern die von zehn Minuten davor gezogen hast. Allerdings habe ich sowas auch während dem Basteln nicht gesehen.

Korrektes Änderungsdatum der exe:
Samstag, 1. Februar 2003 13:20:54

Bitte erstmal checken.

aths

2003-02-01, 14:41:20

Originally posted by zeckensack
Kann ich nicht nachvollziehen :|

Es kann sein, daß du nicht die angekündigte Version, sondern die von zehn Minuten davor gezogen hast. Allerdings habe ich sowas auch während dem Basteln nicht gesehen.

Korrektes Änderungsdatum der exe:
Samstag, 1. Februar 2003 13:20:54

Bitte erstmal checken. Ja, ich habe die korrekte Exe.

aths

2003-02-01, 14:43:09

Noch ein Beispiel:

Warum schafft er es an der einen Stelle nicht, die "Spitze" zu erkennen, wo die Iterationstiefe, wie man an den anderen Stellen sieht, dafür ausreicht?

edit: Und ich kriege solche Dinger am laufendem Bande.

zeckensack

2003-02-01, 14:52:33

Kriegst du solche Fehler auch in der Startauflösung 600x600 hin?

Wenn ja -> bitte eine solche Stelle speichern und places irgendwo hochladen oder mir zumailen.

Ich hab's versucht, aber bisher noch nichts dergleichen gesehen. Ich war IMO an ungefähr den gleichen Stellen, aber die sind alle sauber ???

aths

2003-02-01, 15:01:03

*Mit weiteren Wünschen ankomm*

Wenn Extreme-Floats verwendet werden, bitte schon während des Previews mal die Anzeige refreshen! Das Ding steht sonst ziemlich lange ohne Reaktion.

Spätestens mit Extreme-Floats könnte die Refresh-Rate dann imo drastisch gesenkt werden (Faktor 5 oder 10), aber natürlich sollte es mit beiden Genauigkeiten während der Kern-Berechnung regelmäßige Entgegennamen von Eingaben geben.

aths

2003-02-01, 15:03:35

Originally posted by zeckensack
Kriegst du solche Fehler auch in der Startauflösung 600x600 hin?Ja, natürlich. Lustig: Wird die Interation erst erhöht, und dann wieder auf den alten Wert verringert, sind die Artefakte nicht mehr da sondern alles so wie es soll. Edit: Stimmt doch nicht, hatte mich vertan.

Aber nachdem ich in einem Bild die Iteration erhöhe, sehe ich nie solche Artefakte. Diese sind jedoch nicht nur durch eine zu geringe Iterationstiefe begründbar, weil sowohl Itermax als auch die Auflösung für die unsauberen Stellen ausreicht. Offenbar wird bei einer Erhöhung von Itermax nicht so optimiert wie bei einem neuen Bild?
Originally posted by zeckensack
Wenn ja -> bitte eine solche Stelle speichern und places irgendwo hochladen oder mir zumailen.Die Adresse war...?

zeckensack

2003-02-01, 15:05:49

Originally posted by aths
Ja, natürlich. Lustig: Wird die Interation erst erhöht, und dann wieder auf den alten Wert verringert, sind die Artefakte nicht mehr da sondern alles so wie es soll.
Die Adresse war...? ashopa at gmx dot de

aths

2003-02-01, 15:15:34

*klingel* *klingel* die Post ist da! - edit: doch nicht! ashopa at gmx de funzt nicht.

Ich habe mit den alten Versionen fürs reinzoomen auch immer mit möglichst niedrigem Itermax gearbeitet, und da gabs solche Artefakte nicht.

edit: Dass ich keinen Shice erzähle ist daran festzumachen, dass die alte Exe (ich hab sie hier noch) an dieser Stelle dieses Optimierung-Artefakt nicht zeigt.

zeckensack

2003-02-01, 15:26:57

Theorie:
ooooooooo
oxxxxx---
ox---xxxx
oxxxx----
ooooxxxxx
ooooooooo

o=wird momentan nicht untersucht ('innen')
x=Wanderweg der gleichfarbigen Kontur
-=andere Farbe, begrenzt die aktuell zu findende Kontur

Der Problematische Ausschnitt könnte dieser sein:
-x
x-

Um genaueres sagen zu können, brauche ich einen Stift, ein Blatt Papier und etwas Zeit ?-)

zeckensack

2003-02-01, 15:41:57

Originally posted by zeckensack
Theorie:
ooooooooo
oxxxxx---
ox---xxxx
oxxxx----
ooooxxxxx
ooooooooo

o=wird momentan nicht untersucht ('innen')
x=Wanderweg der gleichfarbigen Kontur
-=andere Farbe, begrenzt die aktuell zu findende Kontur

Der Problematische Ausschnitt könnte dieser sein:
-x
x-

Um genaueres sagen zu können, brauche ich einen Stift, ein Blatt Papier und etwas Zeit ?-)

Aha ...

zeckensack

2003-02-01, 15:45:37

Originally posted by aths
*klingel* *klingel* die Post ist da! - edit: doch nicht! ashopa at gmx de funzt nicht.

Ehrm ...

zeckensack

2003-02-01, 16:20:08

Fix (http://home.t-online.de/~zsack/brot.zip)
Naja, hoffentlich ...
Keine negative Effizienz mehr möglich ?-)
Bei Erhöhung der Iterationstiefe werden nur noch 'neue' Samples gezählt. Dh unter anderem auch, daß wenn das komplette Bild bereits abgedeckt war, jetzt auch 100% Effizienz möglich sind (=> kein einziges neu berechnetes Sample)

Bitte zehn Minuten warten (war diesmal nicht viel zu schreiben).

aths

2003-02-01, 16:34:30

Der Fix ist keiner. Ich habe eine neue Exe, aber weiterhin das Artefakt-Problem:

aths

2003-02-01, 16:36:33

Du kannst mir also ruhig glauben, dass dein Optimierungs-Ansatz fehlerhaft ist. Es muss schon Pixel für Pixel der Rand getract werden, da darf man nicht im Vorhinein irgendwas als Rand schon mal ausschließen. Boundary Tracing versagt ohnehin bei Löchern "im" Kern, die es mathematisch nicht gibt, durch die Digitalisierung aber zustande kommen können. Die Rechteck-Methode ist weitaus sicherer.

Zur Mail:

aths

2003-02-01, 16:42:05

Originally posted by aths
Die Rechteck-Methode ist weitaus sicherer.Beweis: (gleiche Stelle, gleiche Iterationstiefe, neueste und die alte Exe)

zeckensack

2003-02-01, 16:42:37

Originally posted by aths
Der Fix ist keiner. Ich habe eine neue Exe, aber weiterhin das Artefakt-Problem: Ack.

Ich kann dir auch sagen, woran das liegt
xxxxxxxxxx
xoooooooox
xoooooooox
xoooGxxxxx
xoooox----
xooooxxxx-
xoooooooxx
xxxxxxxxxx
o=wird momentan nicht untersucht ('innen')
x=Wanderweg der gleichfarbigen Kontur
-=andere Farbe, begrenzt die aktuell zu findende Kontur
G=Glitch :) Unentdecktes Detail

Der 'Abriß' der Kontur fällt durch die Erkennung durch. Da hilft erstmal höhere Auflösung.

aths

2003-02-01, 16:47:02

Die Optimierung verhaut sich sowieso ganz gerne mal:

Über dem Rechteck, links (neustes Brot, Optimiert) ist das schwarze dicker als rechts (alte adaptive Rechteck-Version)

zeckensack

2003-02-01, 16:52:14

Originally posted by aths
Du kannst mir also ruhig glauben, dass dein Optimierungs-Ansatz fehlerhaft ist. Es muss schon Pixel für Pixel der Rand getract werden, da darf man nicht im Vorhinein irgendwas als Rand schon mal ausschließen. Boundary Tracing versagt ohnehin bei Löchern "im" Kern, die es mathematisch nicht gibt, durch die Digitalisierung aber zustande kommen können.Ich glaube es, ich seh's, und ich verstehe es jetzt sogar :)

Hmmm ... Aliasing :liplick:

Die Rechteck-Methode ist weitaus sicherer.Ja, durch Zufall. Zufall widerstrebt mir leider irgendwie :D

Und beides zu kombinieren wird nicht einfach ... bis abartig kompliziert.

Zur Mail:
keine Ahnung was da los ist. Ich habe jedenfalls an meinem Mail-Zeugs nichts geändert :|