F-Prot für DOS war nicht schlecht. "War" deswegen, weil's seit einigen Monaten keine Updates mehr dafür gibt.
Damit konnte man nicht nur die DOS-Kiste scannen, es lief auch im D*S-Fenster in IksPee und war eine ganz gute Alternative zu diesen blöden Bloatware-Paranoia-Softwaresuiten, die erstmal 15 Systemdienste installieren, ein Icon in die System Tray packen und dauernd ungefragt Updates runterladen, egal, ob man das gerade will oder nicht.
Jetzt versuche ich, mich mit AntiVir zu arrangieren. Immerhin kann man dem Ding per Windows-Policy "verbieten", die EXE-Datei auszuführen, die die nervigen Werbescreens anzeigt. Systemdienste und AutoUpdates hat man natürlich wieder trotzdem, aber immerhin keinen dämlichen Online-Virenscanner, der jede Webseite und jede Datei scannt, die man anklickt.
[RANT]
Tante Käthe und Onkel Heinz mögen sich mit solchen DAU-Sicherheitspaketen ja besser vor bösen, bösen "Hackern" und Viren geschützt fühlen. Mir reicht mein 486er mit FLI4L als Router und Firewall; Internet Exploiter und Outlook nutze ich nicht und unbekannte, ausführbare Dateien scanne ich, bevor ich sie starte. Virenbilanz in den letzten Jahren: Null.
Das sind die Momente, in denen ich die gute alte DOS-Zeit vermisse. Da habe noch *ich* entschieden, wann der Rechner was macht und nicht die Bloatware-Hersteller.
[/RANT]
gute Software für DOS-Maschinen
hawooo!! ^^
hehe "Sie dürfen den Computer nun ausschalten!" dürfen
hehe "Sie dürfen den Computer nun ausschalten!" dürfen
Doch bräucht' es ganze Scharen Von Zauberern, und Zeit
Das Schöne zu bewahren Und die Gerechtigkeit.
Nun will ich nicht mehr weinen. Komm, führ mich in dein Land!
Will mich mit ihr vereinen In deiner sanften Hand...
ASP - Zaubererbruder (Am Ende)
Das Schöne zu bewahren Und die Gerechtigkeit.
Nun will ich nicht mehr weinen. Komm, führ mich in dein Land!
Will mich mit ihr vereinen In deiner sanften Hand...
ASP - Zaubererbruder (Am Ende)
Hallo Dosferatu!
Das stelle ich mir so vor.
Ich schaue mir kurz alle Bilder an, und kopiere die Hochformatbilder in ein separates Verzeichnis. Gebe per Batch mit, ob das Bild rechts- oder links herum gedreht werden soll.
Und lasse die Batch zum drehen der Bilder ablaufen.
Anschließend werden die restlichen Bilder in dieses Verzeichnis kopiert und die SLD-Datei erstellt.
Nun brauche ich nur noch die Show zu starten.
Gibt es ein DOS-Programm was JPEG-Bilder schnell drehen kann?
Gruß Frank
Da ich mir die Digicambilder unter DOS auf meinem Subnotebook anschaue, suche ich noch ein DOS-Programm, das fähig ist die JPEG-Hochformatbilder zu drehen. Dabei sollte es einstellbar sein ob das Bild rechts herum- oder links herum gedreht werden soll.DOSferatu hat geschrieben: ...Konverter und solche Dinge) hab ich mir selbst programmiert. Zum Beispiel schon 3 Malprogramme (1x Textmode, 2x Grafikmode.)
(Mein aktuelles Malprogramm (95% fertig, aber arbeite schon ständig damit), ist halt 8bit (wähl-/ editierbare Farbpalette), und Auflösungen 320x200, 640x400, 640x480, 800x600 und 1024x768.)
...
Das stelle ich mir so vor.
Ich schaue mir kurz alle Bilder an, und kopiere die Hochformatbilder in ein separates Verzeichnis. Gebe per Batch mit, ob das Bild rechts- oder links herum gedreht werden soll.
Und lasse die Batch zum drehen der Bilder ablaufen.
Anschließend werden die restlichen Bilder in dieses Verzeichnis kopiert und die SLD-Datei erstellt.
Nun brauche ich nur noch die Show zu starten.
Gibt es ein DOS-Programm was JPEG-Bilder schnell drehen kann?
Gruß Frank
Ja, PV
kanns aber nich per Batch, sondern auf Tastendruck.
Ich könnte sowas coden für PCX und BMP. JPG ist mir zu kompliziert, hab ich noch nie programmiert. Aber "on the fly" drehen geht bei JPG ja eh nich, weil speziell patternbasiert gepackt und so.
Möglich wäre aber folgendes:
Ne Batch, die erst n Konverter ausführt, (JPG -> PCX) - also z.B. PV oder PictView oder sowas - dann ein kleines Prog von mir, das die PCX-Bilder wie gewünscht dreht, danach wieder Konverter, der die Bilder wieder zurück in JPG rechnet und danach wird das PCX gelöscht, damits nich sinnlos da rumliegt und Speicher verbraucht.
Könnte das auch als EXE schreiben, die a) den Konverter direkt aufruft und b) gleich für alle Bilder im Verzeichnis (bzw alle, die auf ne Joker-Darstellung (z.B. Bla*.JPG oder so) passen den ganzen Schlunz ausführt. Habe für den ganzen Kram selbstgebaute Units da. Das Drehen würde ich (weil's schneller geht) im XMS erledigen. Falls XMS ein Problem sein sollte, könnte ichs auch mit Temp-Files machen, wäre dann aber scheußlich langsam. (Kann gerne erklären, warum.)
Also, wenn Wunsch, bitte melden.
kanns aber nich per Batch, sondern auf Tastendruck.
Ich könnte sowas coden für PCX und BMP. JPG ist mir zu kompliziert, hab ich noch nie programmiert. Aber "on the fly" drehen geht bei JPG ja eh nich, weil speziell patternbasiert gepackt und so.
Möglich wäre aber folgendes:
Ne Batch, die erst n Konverter ausführt, (JPG -> PCX) - also z.B. PV oder PictView oder sowas - dann ein kleines Prog von mir, das die PCX-Bilder wie gewünscht dreht, danach wieder Konverter, der die Bilder wieder zurück in JPG rechnet und danach wird das PCX gelöscht, damits nich sinnlos da rumliegt und Speicher verbraucht.
Könnte das auch als EXE schreiben, die a) den Konverter direkt aufruft und b) gleich für alle Bilder im Verzeichnis (bzw alle, die auf ne Joker-Darstellung (z.B. Bla*.JPG oder so) passen den ganzen Schlunz ausführt. Habe für den ganzen Kram selbstgebaute Units da. Das Drehen würde ich (weil's schneller geht) im XMS erledigen. Falls XMS ein Problem sein sollte, könnte ichs auch mit Temp-Files machen, wäre dann aber scheußlich langsam. (Kann gerne erklären, warum.)
Also, wenn Wunsch, bitte melden.
Ich denk noch drüber nach.DOSferatu hat geschrieben: Also, wenn Wunsch, bitte melden.
Muß noch ausprobieren wie lange PV braucht, um JPEG in PCX zu konvertieren. Wenn die Zeit mehr als 2 Min pro Bild dauert, dann finde ich es zu lange wenn die Konvertierung für 30 Bilder erst 60 Minuten dauert.
Ich weiß nicht, wie man das bei JPEG macht. Ich weiß aber, daß es da die Bilddrehung verlustfrei gibt, weil nur IMHO zwei Werte ausgetauscht werden müssen.
Irgendwie hatte ich mir eine Lösung vorgestellt, ohne daß das Bild dabei angezeigt wird. Quasi ein Austausch der Parameter per Batch oder so.
Gruß Frank
Bild drehen
Hallo DOSferatu!
Ich würde dein Angebot gerne annehmen wollen.
PV benötigt für die Konvertierung von 10 Bildern (4 Megapixel) von LPEG nach PCX rund 3 Minuten, das ist für mein Empfinden relativ schnell.
Ich habe es mir folgendermaßen vorgestellt.
Ich schaue mir die Bilder kurz an und verschiebe die Hochkantbilder in zwei verschiedene Verzeichnise. Die Bilder, die rechts herum gedreht werden sollen in das eine Verzeichnis, und die Bilder, die links herum gedreht werden sollen in das andere Verzeichnis.
Anschließend wandle ich die Bilder in PCX um.
Dann rufe ich dein Programm auf, daß die Bilder richtig herum dreht.
Anschließend verschiebe ich die PCX-Bilder zu den Bildern die nicht gedreht werden brauchten und erstelle davon die Slideshow.
Nach der Slideshow werden die PCX-Bilder gelöscht, und die JPEG-Bilder wieder zurückverschoben.
Was muß dein Programm können?
Man muß es in eine Batch einbinden können (durch eine Batch ausführen lassen können, und anschließend in der Batch fortfahren können).
Es muß zwei Parameter besitzen, einmal für Rechtsdrehung und einmal für Linksdrehung.
Ich muß den Verzeichnispfad mit übergeben können, in dem sich die PCX-Bilder befinden.
Ich photographiere nur mit 4 Megapixeln. Die Bilder sind immer 2272x1704 Pixel groß.
Gruß Frank
Ich würde dein Angebot gerne annehmen wollen.
PV benötigt für die Konvertierung von 10 Bildern (4 Megapixel) von LPEG nach PCX rund 3 Minuten, das ist für mein Empfinden relativ schnell.
Ich habe es mir folgendermaßen vorgestellt.
Ich schaue mir die Bilder kurz an und verschiebe die Hochkantbilder in zwei verschiedene Verzeichnise. Die Bilder, die rechts herum gedreht werden sollen in das eine Verzeichnis, und die Bilder, die links herum gedreht werden sollen in das andere Verzeichnis.
Anschließend wandle ich die Bilder in PCX um.
Dann rufe ich dein Programm auf, daß die Bilder richtig herum dreht.
Anschließend verschiebe ich die PCX-Bilder zu den Bildern die nicht gedreht werden brauchten und erstelle davon die Slideshow.
Nach der Slideshow werden die PCX-Bilder gelöscht, und die JPEG-Bilder wieder zurückverschoben.
Was muß dein Programm können?
Man muß es in eine Batch einbinden können (durch eine Batch ausführen lassen können, und anschließend in der Batch fortfahren können).
Es muß zwei Parameter besitzen, einmal für Rechtsdrehung und einmal für Linksdrehung.
Ich muß den Verzeichnispfad mit übergeben können, in dem sich die PCX-Bilder befinden.
Ich photographiere nur mit 4 Megapixeln. Die Bilder sind immer 2272x1704 Pixel groß.
Gruß Frank
Ja, da werd ich (bei 2272x1704x24bit) geringfügig mehr als 11 MB (2272x1704x3 bytes) XMS brauchen. Aber nehme an, das wird vorhanden sein. Selbstredend werden die PCX-Bilder natürlich bekloppt groß werden, weil PCX ja außer Lauflängen-Packen (was bei 24bit - also ohne Palette - ja nahezu witzlos ist) keinerlei sonstiges Packen stattfindet.
Also, ich mach das Tool mit folgenden möglichen Parametern:
Beispiel:
C:\BILDER\RECHTS\*.PCX
Ein Parameter, der nicht mit / oder - beginnt, ist der Quellparameter. Hier kann ein Bildfile oder ein Pfad mit Bildfile angegeben werden. Bei dem File selbst können auch Jokers (also ? und *) benutzt werden - für alle Bilder also *.*
Wenn man nur einen Pfad angibt (muß dann mit \ enden!!!), werden automatisch alle PCX-Bilder in diesem Pfad (Verzeichnis) gewandelt. Man kann unvollständige Pfade angeben - dann wird ausgehend vom aktuellen Verzeichnis herunterverzweigt.Gibt man diesen Parameter gar nicht an, also weder ein Pfad noch ein Bild oder eine "Maske" (also mit Jokers), werden alle PCX-Bilder im aktuellen Verzeichnis gewandelt.
Die anderen Parameter sind:
(Groß/Kleinscheibung egal, es kann auch - statt / benutzt werden, um Parameter zu trennen)
/L /R /X /Y /T
/L dreht das Bild um 90° nach links
/R dreht das Bild um 90° nach rechts
/X spiegelt das Bild an der X-Achse
/Y spiegelt das Bild an der Y-Achse
/T dreht das Bild um 180° (stellt es auf den Kopf)
Es wäre zwar theoretisch möglich, mehrere dieser Parameter zu benutzen, aber es ist, wie man (wenn man darüber nachdenkt) sieht, sinnlos, da die Kombination mehrerer dieser Parameter als Ergebnis wieder einen einzelnen dieser Parameter ergeben werden.
Der Parameter /N
Wird der Parameter /N angegeben, so wird das Ursprungsbild von Bildname.PCX in Bildname.PCY umbenannt (die meisten Bildleser/Konverter, die ich kenne, auch PV, lesen übrigens auch PCY!) und das NEUE Bild heißt dann Bildname.PCX.
Läßt man den Parameter /N (für "new") weg, so wird das Ursprungsbild mit dem neuen Bild einfach überschrieben.
Anmerkung:
Eventuell wird es - wenn ich Lust habe - in späteren Versionen noch 2 Parameter namens /W und /H geben, mit denen man eine neue Breite (width) und Höhe (height) für das Bild angeben kann - vielleicht auch wahlweise mit Prozenten. Und wenn mich der Hafer stechen sollte, dann vielleicht auch mit interpolierten Pixeln, damit bei Vergrößerung keine Klotzpixel entstehen... Naja, muß mir das noch überlegen...
Ich hoffe, daß das so in etwa Deinen Vorstellungen entsprechen wird.
Also, ich mach das Tool mit folgenden möglichen Parametern:
Beispiel:
C:\BILDER\RECHTS\*.PCX
Ein Parameter, der nicht mit / oder - beginnt, ist der Quellparameter. Hier kann ein Bildfile oder ein Pfad mit Bildfile angegeben werden. Bei dem File selbst können auch Jokers (also ? und *) benutzt werden - für alle Bilder also *.*
Wenn man nur einen Pfad angibt (muß dann mit \ enden!!!), werden automatisch alle PCX-Bilder in diesem Pfad (Verzeichnis) gewandelt. Man kann unvollständige Pfade angeben - dann wird ausgehend vom aktuellen Verzeichnis herunterverzweigt.Gibt man diesen Parameter gar nicht an, also weder ein Pfad noch ein Bild oder eine "Maske" (also mit Jokers), werden alle PCX-Bilder im aktuellen Verzeichnis gewandelt.
Die anderen Parameter sind:
(Groß/Kleinscheibung egal, es kann auch - statt / benutzt werden, um Parameter zu trennen)
/L /R /X /Y /T
/L dreht das Bild um 90° nach links
/R dreht das Bild um 90° nach rechts
/X spiegelt das Bild an der X-Achse
/Y spiegelt das Bild an der Y-Achse
/T dreht das Bild um 180° (stellt es auf den Kopf)
Es wäre zwar theoretisch möglich, mehrere dieser Parameter zu benutzen, aber es ist, wie man (wenn man darüber nachdenkt) sieht, sinnlos, da die Kombination mehrerer dieser Parameter als Ergebnis wieder einen einzelnen dieser Parameter ergeben werden.
Der Parameter /N
Wird der Parameter /N angegeben, so wird das Ursprungsbild von Bildname.PCX in Bildname.PCY umbenannt (die meisten Bildleser/Konverter, die ich kenne, auch PV, lesen übrigens auch PCY!) und das NEUE Bild heißt dann Bildname.PCX.
Läßt man den Parameter /N (für "new") weg, so wird das Ursprungsbild mit dem neuen Bild einfach überschrieben.
Anmerkung:
Eventuell wird es - wenn ich Lust habe - in späteren Versionen noch 2 Parameter namens /W und /H geben, mit denen man eine neue Breite (width) und Höhe (height) für das Bild angeben kann - vielleicht auch wahlweise mit Prozenten. Und wenn mich der Hafer stechen sollte, dann vielleicht auch mit interpolierten Pixeln, damit bei Vergrößerung keine Klotzpixel entstehen... Naja, muß mir das noch überlegen...
Ich hoffe, daß das so in etwa Deinen Vorstellungen entsprechen wird.
Der Rechner hat zwar nur 32 MB Ram, aber zur Not gibt es ja Auslagerungsdateien.
Falls Speichermäßig was nicht hinhaut dann hilft mir mein Startmenü weiter, mit dem ich verschiedene Konfigurationen laden kann.
Bei meinen Probekonvertierungen waren die PCX-Bilder zwischen 11 und 13 MB groß.
Das was du vorhast, ist mehr als ich will.
Schon mal DANKE im Vorraus.
Gruß Frank
Falls Speichermäßig was nicht hinhaut dann hilft mir mein Startmenü weiter, mit dem ich verschiedene Konfigurationen laden kann.
Bei meinen Probekonvertierungen waren die PCX-Bilder zwischen 11 und 13 MB groß.
Das was du vorhast, ist mehr als ich will.
Schon mal DANKE im Vorraus.
Gruß Frank
Hab jetzt 12 Stunden an dem Ding rumgebastelt und dann noch 2 Stunden für Anleitung und ums für die Webseite fertig zu machen.
Das Tool heißt TURNPIC und kann auf meiner Seite heruntergeladen werden:
http://www.imperial-games.de/html/dosa3.htm
Eine deutsche Anleitung liegt bei. Eine "Direkt-Hilfe" kann mit /? oder -? aufgerufen werden.
Für Deine Bilder braucht das Programm ca. 14,8 MB freien XMS (im Klartext: 15485952 Bytes). Im Moment arbeitet es mit einer generalisierten Routine. Ich werde da vielleicht noch etwas dran herumfrickeln, dann braucht es später etwas weniger.
Ich weiß nicht, wie schnell es auf Deinem Rechner sein wird. Problem ist eben, daß dieser indirekte Zugriff auf XMS (im 16bit Mode, mit HIMEM) leider nicht gerade der schnellste ist. Hoffe, daß es auf Deinem Rechner einigermaßen performt.
Probier es halt aus und sage bescheid, wenn es noch irgendwelche Wünsche gibt.
Das Tool heißt TURNPIC und kann auf meiner Seite heruntergeladen werden:
http://www.imperial-games.de/html/dosa3.htm
Eine deutsche Anleitung liegt bei. Eine "Direkt-Hilfe" kann mit /? oder -? aufgerufen werden.
Für Deine Bilder braucht das Programm ca. 14,8 MB freien XMS (im Klartext: 15485952 Bytes). Im Moment arbeitet es mit einer generalisierten Routine. Ich werde da vielleicht noch etwas dran herumfrickeln, dann braucht es später etwas weniger.
Ich weiß nicht, wie schnell es auf Deinem Rechner sein wird. Problem ist eben, daß dieser indirekte Zugriff auf XMS (im 16bit Mode, mit HIMEM) leider nicht gerade der schnellste ist. Hoffe, daß es auf Deinem Rechner einigermaßen performt.
Probier es halt aus und sage bescheid, wenn es noch irgendwelche Wünsche gibt.
Hallo Dosferatu!
Manchmal hat man weniger Zeit.
Sorry, war keine Absicht.
Habe nicht gedacht, daß du so schnell bist.
Programm habe ich runtergeladen, aber wegen Zeitmangel noch nicht getestet.
Ich werde ab morgen für eine Woche weg und nicht erreichbar sein (auch nicht online) und muß bis dahin noch viel erledigen.
Ich hoffe, daß ich abends ein wenig Zeit habe das Proggy zu testen.
Jetzt erst einmal vorneweg ein riesiges DANKESCHÖN an dich.
Gruß Frank
Manchmal hat man weniger Zeit.
Sorry, war keine Absicht.
Habe nicht gedacht, daß du so schnell bist.
Programm habe ich runtergeladen, aber wegen Zeitmangel noch nicht getestet.
Ich werde ab morgen für eine Woche weg und nicht erreichbar sein (auch nicht online) und muß bis dahin noch viel erledigen.
Ich hoffe, daß ich abends ein wenig Zeit habe das Proggy zu testen.
Jetzt erst einmal vorneweg ein riesiges DANKESCHÖN an dich.
Gruß Frank
Hallo Dosferatu!
Bin jetzt zurück, und konnte das Programm testen...
Im Prinzip funktioniert es so, wie ich es möchte aaaabbbeeerrrr....
Die ersten 50% der Bildbearbeitung sind nach ca. 25 Sekunden beendet, dann stockt kurz die Prozentangabe bei genau 50% und der Rest wird in ca. 5 Minuten und 35 Sekunden (pro Bild !!!) bearbeitet.
6 Minuten pro 4 Megapixel-Bild sind mir ein bischen zu lange.
Bei 20 Bildern wäre ich da bei 2 Stunden bearbeitungszeit.
Kann man da noch was drehen an der Geschindigkeit?
XMS werden 28 MB erkannt (von den 32 MB verfügbaren).
Gruß Frank
Bin jetzt zurück, und konnte das Programm testen...
Im Prinzip funktioniert es so, wie ich es möchte aaaabbbeeerrrr....
Die ersten 50% der Bildbearbeitung sind nach ca. 25 Sekunden beendet, dann stockt kurz die Prozentangabe bei genau 50% und der Rest wird in ca. 5 Minuten und 35 Sekunden (pro Bild !!!) bearbeitet.
6 Minuten pro 4 Megapixel-Bild sind mir ein bischen zu lange.
Bei 20 Bildern wäre ich da bei 2 Stunden bearbeitungszeit.
Kann man da noch was drehen an der Geschindigkeit?
XMS werden 28 MB erkannt (von den 32 MB verfügbaren).
Gruß Frank
Das mit den Prozenten ist leicht zu erklären:
In den ersten 50% liest er das Bild in den XMS. In den zweiten 50% holt er's aus dem XMS und schreibt es gedreht zurück. Das heißt, die Prozentangabe "stockt" nicht, sondern es sind zwei unterschiedliche Routinen, wobei die Leseroutine schneller arbeitet als die kombinierte Konvertier-/Schreibroutine.
Und das ist die Erklärung:
Beim Lesen kann er natürlich linear lesen und die Daten blockweise ins XMS schreiben.
Beim Schreiben muß er die Daten pixelweise aus dem XMS holen - aber XMS-Zugriffe dauern halt, weil sie indirekt sind - und um es halt "quer" zu lesen, muß ich jeden Pixel einzeln holen.
Es sind bei Deinen Bildern pro Bild etwas über 11 MB, die ich dann fast byteweise lese und schreibe. Weil ein Pixel ja 3 Byte hat. Die Pixel werden von mir als DWORDs (4 Byte) gelesen (weil man bei XMS bei den Zugriffen nur gerade Anzahlen Bytes lesen/schreiben kann - liegt an HIMEM.SYS, das ist da so Standard.)
Zu XMS: Es werden IMMER weniger XMS "erkannt", als da sind. Ich gebe da nicht den Gesamt-XMS aus (der dann 32MB wäre), sondern den größten verfügbaren (freien) "Block". Auch andere Programme benutzen XMS: Bei manchen Rechnern sind die unteren 1 MB das erste MB des "XMS". Außerdem wird HMA auch im "XMS" abgelegt (über 1 MB). Desweiteren gibt es Systeme mit "Shared Memory", d.h. die Grafikkarte/Grafikchip (vor allem bei Grafikchips - die haben im Gegensatz zu Karten meistens keinen eigenen Speicher) benutzt einen Teil dieses RAMs als Grafik-RAM. Außerdem kann der XMS etwas "fragmentiert" sein, d.h. es kann etwas im XMS belegt worden sein, dann noch etwas, und das "noch etwas" wurde wieder freigegeben, das erste aber nicht - dann ist zwar mehr XMS frei, aber eben kein zusammenhängender Block. Man kann XMS nur blockweise (mit "Handles") belegen. Um andere evtl vorhandene kleinere Bereiche zu belegen, müßte man mit mehreren Handles arbeiten. Das würde aber die Bearbeitung weiter verkomplizieren (und im Klartext auch verlangsamen).
Mit den 28 freien MB sollte es aber keine Probleme geben, da es für die Bearbeitung von Bildern der gewünschten Größe nur ca. 15 MB benötigt.
Zur Geschwindigkeit: Da ich XMS benutze und die Bilder so groß sind, ahnte ich, daß die Performance nicht so besonders sein würde. Bessere Ergebnisse (also dann ca. 50 Sekunden bis 1 Minute pro Bild, weil die zweiten 50% dann etwa so schnell wären wie die ersten) könnte man nur erzielen, wenn man das Ganze im Protected Mode oder im "Fake"-4G-Mode (auch Real Huge Memory Mode) macht - weil man dann direkten Zugriff auf den ganzen Speicher hätte, statt den indirekten Zugriff per XMS (über HIMEM.SYS). Ich kann aber keinen Protected Mode programmieren und auch keinen "Real Huge/4G" Mode, weiß nur rein theoretisch, wie die funktionieren.
Zur Arbeitsweise XMS:
HIMEM.SYS/XMS arbeitet so, daß man nur Speicherbereiche aus dem Heap-Bereich (unter 1 MB) ins XMS schreiben und Bereiche aus dem XMS in den Heap-Bereich kopieren kann. Bei einer Breite von 2272 Pixeln KÖNNTE ich noch so vorgehen, daß ich 9088 Bytes * X in den Heap kopiere, also einen Heap-Bereich von Vorhandener_Rest_Heap als Ziel benutze und dieser Bereich / 9088 wäre dann die "Zeilenzahl", also sozusagen (weil gedreht) die nebeneinanderliegenden Pixel. Angenommen, ich hätte 300 kB frei könnte ich damit 33 Pixel pro XMS-Zugriff (statt 1) haben - aber dann würde ich eben nicht pro Pixel 4, sondern 9088 Bytes kopieren - und ich bezweifle, ob das dann wirklich schneller werden würde. Es wären weniger XMS-Blockzugriffe, dafür wären es aber viel mehr Blockdaten. Und wenn ich pro Pixel statt 4 nur 3 Bytes verwenden würde, würde sich das zwar reduzieren - aber da es keine 3-Byte Register oder 3-Byte-Variablen auf x86 PCs gibt, wären es pro zu bearbeitendem Pixel mindestens 2 Bearbeitungen, weil man es maximal mit einem Word und einem Byte realisieren könnte. (PCX speichert die 3 "Phasen" (R,G,B) im 24 Bit-Format untereinander, d.h. es hat immer im Wechsel eine "rote", eine "grüne" und eine "blaue" Zeile...
Das Problem ist leider, daß jede Erhöhung der Geschwindigkeit in einem Bereich eine Verminderung der Geschwindigkeit in einem anderen Bereich bedeuten würde (kompliziertere Bearbeitungen erfordern höheren Beabeitungsaufwand, der dann wieder auf die Geschwindigkeit schlägt).
Es ist schade - aber im "Real Mode" (16 Bit) sehe ich kaum noch eine Möglichkeit, die Berechnungsgeschwindigkeit um akzeptable Faktoren zu erhöhen.
Die 3 Ausrufezeichen hinter der Zeitangabe (6 Minuten, bzw 0:25 + 5:35) sind also völlig unnötig. Ich habe hier ein PCX-Bild mit 2272 x 1704 Pixeln, 24 Bit erstellt (habe ein anderes Bild so gestreckt, daß es paßt. Hab so große Bilder nich. Aber der Bildinhalt spielt bei der Bearbeitungsgeschwindigkeit keine Rolle, das geringe Lauflängenpacken bei 24bit PCX macht da wahrscheinlich nichtmal n Bruchteil einer Sekunde aus. Weil es ja beim Laden entpackt und beim Speichern gepackt wird, also das ungepackte Bild bearbeitet wird.
Ich habe es bei mir getestet (mit so einem Bild) und es hängt zwar teilweise vom CPU-Modell ab (aber nur ein wenig), hauptsächlich jedoch direkt von der Taktfrequenz, also den MHz der CPU.
486er DX4, 133 MHz: 9 min, 08 sek (548 Sekunden)
586er, 333 MHz: 3 min, 29 sek (209 Sekunden)
Benutzt man den Dreisatz und ignoriert die durch die verschiedene CPU-Architektur entstehende leichte Ungenauigkeit, kommt man zu dem Schluß, daß Dein Rechner, der dafür 6 min, 0 sek (360 Sekunden) braucht, ein Rechner mit 200 MHz sein müßte.
Zur Performance hatte ich ja "gewarnt"... Glaube auch kaum, daß ein anderes 16-Bit Programm es schneller hinkriegen würde. Wie gesagt: Protected- oder 4G (Real Huge) Mode wäre 'ne Möglichkeit, wegen des direkten "XMS"-Zugriffs. Dann würde ein Bild (schätzungsweise) so ca. 50 bis 55 Sekunden für die Drehung brauchen.
Im Moment code ich gerade für einen Kumpel zwei Tools. Aber bei Gelegenheit, wenn ich Zeit und Lust habe, probiere ich noch einmal den beschriebenen Weg mit der größeren XMS-Blöcke-Rückkopier-Aktion. Aber ich befürchte, daß es dadurch nicht wirklich viel schneller wird - und die komplexere Bearbeitung könnte den geringen Geschwindigkeitsgewinn, der dadurch evtl erreicht werden könnte, wieder auffressen.
In den ersten 50% liest er das Bild in den XMS. In den zweiten 50% holt er's aus dem XMS und schreibt es gedreht zurück. Das heißt, die Prozentangabe "stockt" nicht, sondern es sind zwei unterschiedliche Routinen, wobei die Leseroutine schneller arbeitet als die kombinierte Konvertier-/Schreibroutine.
Und das ist die Erklärung:
Beim Lesen kann er natürlich linear lesen und die Daten blockweise ins XMS schreiben.
Beim Schreiben muß er die Daten pixelweise aus dem XMS holen - aber XMS-Zugriffe dauern halt, weil sie indirekt sind - und um es halt "quer" zu lesen, muß ich jeden Pixel einzeln holen.
Es sind bei Deinen Bildern pro Bild etwas über 11 MB, die ich dann fast byteweise lese und schreibe. Weil ein Pixel ja 3 Byte hat. Die Pixel werden von mir als DWORDs (4 Byte) gelesen (weil man bei XMS bei den Zugriffen nur gerade Anzahlen Bytes lesen/schreiben kann - liegt an HIMEM.SYS, das ist da so Standard.)
Zu XMS: Es werden IMMER weniger XMS "erkannt", als da sind. Ich gebe da nicht den Gesamt-XMS aus (der dann 32MB wäre), sondern den größten verfügbaren (freien) "Block". Auch andere Programme benutzen XMS: Bei manchen Rechnern sind die unteren 1 MB das erste MB des "XMS". Außerdem wird HMA auch im "XMS" abgelegt (über 1 MB). Desweiteren gibt es Systeme mit "Shared Memory", d.h. die Grafikkarte/Grafikchip (vor allem bei Grafikchips - die haben im Gegensatz zu Karten meistens keinen eigenen Speicher) benutzt einen Teil dieses RAMs als Grafik-RAM. Außerdem kann der XMS etwas "fragmentiert" sein, d.h. es kann etwas im XMS belegt worden sein, dann noch etwas, und das "noch etwas" wurde wieder freigegeben, das erste aber nicht - dann ist zwar mehr XMS frei, aber eben kein zusammenhängender Block. Man kann XMS nur blockweise (mit "Handles") belegen. Um andere evtl vorhandene kleinere Bereiche zu belegen, müßte man mit mehreren Handles arbeiten. Das würde aber die Bearbeitung weiter verkomplizieren (und im Klartext auch verlangsamen).
Mit den 28 freien MB sollte es aber keine Probleme geben, da es für die Bearbeitung von Bildern der gewünschten Größe nur ca. 15 MB benötigt.
Zur Geschwindigkeit: Da ich XMS benutze und die Bilder so groß sind, ahnte ich, daß die Performance nicht so besonders sein würde. Bessere Ergebnisse (also dann ca. 50 Sekunden bis 1 Minute pro Bild, weil die zweiten 50% dann etwa so schnell wären wie die ersten) könnte man nur erzielen, wenn man das Ganze im Protected Mode oder im "Fake"-4G-Mode (auch Real Huge Memory Mode) macht - weil man dann direkten Zugriff auf den ganzen Speicher hätte, statt den indirekten Zugriff per XMS (über HIMEM.SYS). Ich kann aber keinen Protected Mode programmieren und auch keinen "Real Huge/4G" Mode, weiß nur rein theoretisch, wie die funktionieren.
Zur Arbeitsweise XMS:
HIMEM.SYS/XMS arbeitet so, daß man nur Speicherbereiche aus dem Heap-Bereich (unter 1 MB) ins XMS schreiben und Bereiche aus dem XMS in den Heap-Bereich kopieren kann. Bei einer Breite von 2272 Pixeln KÖNNTE ich noch so vorgehen, daß ich 9088 Bytes * X in den Heap kopiere, also einen Heap-Bereich von Vorhandener_Rest_Heap als Ziel benutze und dieser Bereich / 9088 wäre dann die "Zeilenzahl", also sozusagen (weil gedreht) die nebeneinanderliegenden Pixel. Angenommen, ich hätte 300 kB frei könnte ich damit 33 Pixel pro XMS-Zugriff (statt 1) haben - aber dann würde ich eben nicht pro Pixel 4, sondern 9088 Bytes kopieren - und ich bezweifle, ob das dann wirklich schneller werden würde. Es wären weniger XMS-Blockzugriffe, dafür wären es aber viel mehr Blockdaten. Und wenn ich pro Pixel statt 4 nur 3 Bytes verwenden würde, würde sich das zwar reduzieren - aber da es keine 3-Byte Register oder 3-Byte-Variablen auf x86 PCs gibt, wären es pro zu bearbeitendem Pixel mindestens 2 Bearbeitungen, weil man es maximal mit einem Word und einem Byte realisieren könnte. (PCX speichert die 3 "Phasen" (R,G,B) im 24 Bit-Format untereinander, d.h. es hat immer im Wechsel eine "rote", eine "grüne" und eine "blaue" Zeile...
Das Problem ist leider, daß jede Erhöhung der Geschwindigkeit in einem Bereich eine Verminderung der Geschwindigkeit in einem anderen Bereich bedeuten würde (kompliziertere Bearbeitungen erfordern höheren Beabeitungsaufwand, der dann wieder auf die Geschwindigkeit schlägt).
Es ist schade - aber im "Real Mode" (16 Bit) sehe ich kaum noch eine Möglichkeit, die Berechnungsgeschwindigkeit um akzeptable Faktoren zu erhöhen.
Die 3 Ausrufezeichen hinter der Zeitangabe (6 Minuten, bzw 0:25 + 5:35) sind also völlig unnötig. Ich habe hier ein PCX-Bild mit 2272 x 1704 Pixeln, 24 Bit erstellt (habe ein anderes Bild so gestreckt, daß es paßt. Hab so große Bilder nich. Aber der Bildinhalt spielt bei der Bearbeitungsgeschwindigkeit keine Rolle, das geringe Lauflängenpacken bei 24bit PCX macht da wahrscheinlich nichtmal n Bruchteil einer Sekunde aus. Weil es ja beim Laden entpackt und beim Speichern gepackt wird, also das ungepackte Bild bearbeitet wird.
Ich habe es bei mir getestet (mit so einem Bild) und es hängt zwar teilweise vom CPU-Modell ab (aber nur ein wenig), hauptsächlich jedoch direkt von der Taktfrequenz, also den MHz der CPU.
486er DX4, 133 MHz: 9 min, 08 sek (548 Sekunden)
586er, 333 MHz: 3 min, 29 sek (209 Sekunden)
Benutzt man den Dreisatz und ignoriert die durch die verschiedene CPU-Architektur entstehende leichte Ungenauigkeit, kommt man zu dem Schluß, daß Dein Rechner, der dafür 6 min, 0 sek (360 Sekunden) braucht, ein Rechner mit 200 MHz sein müßte.
Zur Performance hatte ich ja "gewarnt"... Glaube auch kaum, daß ein anderes 16-Bit Programm es schneller hinkriegen würde. Wie gesagt: Protected- oder 4G (Real Huge) Mode wäre 'ne Möglichkeit, wegen des direkten "XMS"-Zugriffs. Dann würde ein Bild (schätzungsweise) so ca. 50 bis 55 Sekunden für die Drehung brauchen.
Im Moment code ich gerade für einen Kumpel zwei Tools. Aber bei Gelegenheit, wenn ich Zeit und Lust habe, probiere ich noch einmal den beschriebenen Weg mit der größeren XMS-Blöcke-Rückkopier-Aktion. Aber ich befürchte, daß es dadurch nicht wirklich viel schneller wird - und die komplexere Bearbeitung könnte den geringen Geschwindigkeitsgewinn, der dadurch evtl erreicht werden könnte, wieder auffressen.