Hallo DOSferatu!
Erst einmal recht herzlichen Dank für die sehr ausführliche Erklärung.
Mit der CPU-Geschwindigkeit hast du recht, es ist ein Penndumm mit 233 MHz.
Bei Gelegenheit probiere ich mal aus, die Bilder vielleicht in der Größe zu reduzieren, da der Libretto nur ein 7,1-Zoll-Display mit 800x480 Bildpunkten hat.
Wenn bei der Reduzierung die Bildqualität nicht zu sehr leidet, dann geht die Dehung sicherlich auch schneller.
In PV kann man zwar auch die Bilder drehen wenn sie angezeigt werden, ich habe es aber bisher nicht geschafft im Anzeigemodus das komplette Bild anzeigen zu lassen.
Speichere ich es anschließend neu ab, wird nur der sichtbare Teil des Bildes abgespeichert, und der Rest abgeschnitten.
Gruß Frank
gute Software für DOS-Maschinen
Ja, genau. Der (PV) kann das nur innerhalb des sichtbaren Bereiches drehen, der dreht das innerhalb des Grafikspeichers. Davon abgesehen zeigt er (außer, wenn anders eingestellt) das Bild sowieso verkleinert an, d.h. er lädt 2272x1704 aber zeigt es natürlich nur in der vorhandenen maximalen Auflösung an. Außer man stellt es halt ein - dann kann er es auch auf "Vollbild" zerren (Schwachsinn, weil er dann unformatige Bilder einfach so zerrt, daß es genau in die Auflösung paßt - dann stimmt ja das Verhältnis von Breite und Höhe des Bildes nicht mehr). Oder auf "Ausschnitt", dann zeigt er einen Ausschnitt des Bildes, den man mit der Maus oder den Cursortasten hin- und herschieben kann. ABER: Wenn er das Bild dreht oder sonstwie bearbeitet, tut er das dann nur für den jeweilig sichtbaren Bildausschnitt. Achja: Wenn er diese Option (Ausschnitt) benutzt, lädt er das Bild vorher in den XMS. Leider dreht er's nicht im XMS sondern, wie erwähnt, im (sichtbaren) Grafikspeicher.
Und ja - bei kleinerer Bildgröße reduziert sich definitiv die benötigte Zeit. Ein 2272x1704-Bild, verkleinert auf 800x480 sollte (Dreisatz) auf Deinem Rechner knapp 36 Sekunden dauern.
Und ja - bei kleinerer Bildgröße reduziert sich definitiv die benötigte Zeit. Ein 2272x1704-Bild, verkleinert auf 800x480 sollte (Dreisatz) auf Deinem Rechner knapp 36 Sekunden dauern.
Nachtrag: Wobei es natürlich Blödsinn wäre, ein 2272x1704 Bild auf 800x480 zu konvertieren. 2272x1704 wäre ja 4:3 Format. Um also das Verhältnis von Breite und Höhe beizubehalten, müßte man das Bild auf 640x480 runterverkleinern. Will man Breite 800, müßte die Höhe 600 sein - in dem Fall paßt das Bild jedoch nicht vollständig auf den Bildschirm.
Ein 800x600-Bild würde auf Deinem Rechner knapp 45 Sekunden dauern.
Ein 640x480-Bild wäre in knapp 29 Sekunden fertig.
Ein 800x600-Bild würde auf Deinem Rechner knapp 45 Sekunden dauern.
Ein 640x480-Bild wäre in knapp 29 Sekunden fertig.
Hallo DOSferatu!
Erst einmal vielen herzlichen Dank für deine Bemühungen.
Das mit dem Seitenverhältnis ist mir schon klar.
Auch bei der jetzigen Anzeige die ich momentan benutze, wird ein wenig des unteren Bildrandes abgeschnitten um das Bild formatfüllend anzeigen zu können.
Da ich das Drehen der Hochformatbilder nur dazu brauche, um im Urlaub mal die Bilder abends auf einem größeren Display (als dem Kameradisplay) anschauen zu können, die bearbeiteten Bilder aber anschließend wieder gelöscht- und nicht weiterverarbeitet werden wäre eine Konvertierung in ein kleineres Bild sinnvoll, wenn es dadurch insgesamt zu einer spürbaren Zeitersparnis kommt.
Gefühlsmäßig möchte ich nicht länger als 15 Minuten für 20 Hochkantbilder warten wollen bis ich die Slideshow starten kann.
Ich kann noch nicht sagen, wann ich zum ausprobieren (Konvertierung) kommen werde, da ab heute meine 7-Tage-Nachtschicht beginnt, und ich nicht absehen kann, ob- und wann ich Zeit dazu haben werde.
Gruß Frank
Erst einmal vielen herzlichen Dank für deine Bemühungen.
Das mit dem Seitenverhältnis ist mir schon klar.
Auch bei der jetzigen Anzeige die ich momentan benutze, wird ein wenig des unteren Bildrandes abgeschnitten um das Bild formatfüllend anzeigen zu können.
Da ich das Drehen der Hochformatbilder nur dazu brauche, um im Urlaub mal die Bilder abends auf einem größeren Display (als dem Kameradisplay) anschauen zu können, die bearbeiteten Bilder aber anschließend wieder gelöscht- und nicht weiterverarbeitet werden wäre eine Konvertierung in ein kleineres Bild sinnvoll, wenn es dadurch insgesamt zu einer spürbaren Zeitersparnis kommt.
Gefühlsmäßig möchte ich nicht länger als 15 Minuten für 20 Hochkantbilder warten wollen bis ich die Slideshow starten kann.
Ich kann noch nicht sagen, wann ich zum ausprobieren (Konvertierung) kommen werde, da ab heute meine 7-Tage-Nachtschicht beginnt, und ich nicht absehen kann, ob- und wann ich Zeit dazu haben werde.
Gruß Frank
Normalerweise müßtest Du ja jetzt, um die Bilder zu verkleinern (odervergrößern) vorher ein Konvertier-Programm starten, das die Bilder entsprechend verkleinert. Und danach dann das TURNPIC. Aber wie bereits erwähnt, werde ich da noch Parameter einbauen, damit TURNPIC gleichzeitig (also im selben Durchlauf - NICHT nacheinander oder so!) die Größe des Bildes gleich mitändern kann. Auf die Art bräuchte man dann nicht zwei verschiedene Programme zu benutzen, sondern TURNPIC würde das Bild gleichzeitig verkleinern UND drehen.
Wie wäre das?
(Anmerkung: Bei Konvertierung in 800x600 würden (laut meiner Berechnung) die gewünschten 15 Minuten für 20 Bilder erreicht werden.)
Wie wäre das?
(Anmerkung: Bei Konvertierung in 800x600 würden (laut meiner Berechnung) die gewünschten 15 Minuten für 20 Bilder erreicht werden.)
naja normal ist da neben DOS nur der Norton Commander drauf, grafik mach ich an meiner DOS Kiste nicht, und Layout auch nicht
naja gut Windows 3.11 ist nocht drauf weil ich mit den DOS Kisten eigentlich wirklich nurnoch spiele
auf meinem 386er ist noch PCTools drauf, aber das irgendwie nurnoch damit der rechne im einkaufszustand ist, da fehlt mir nurnoch dieses Highscree Einweisungs System.. :(
naja gut Windows 3.11 ist nocht drauf weil ich mit den DOS Kisten eigentlich wirklich nurnoch spiele
auf meinem 386er ist noch PCTools drauf, aber das irgendwie nurnoch damit der rechne im einkaufszustand ist, da fehlt mir nurnoch dieses Highscree Einweisungs System.. :(
Hallo Dosferatu!
Ich habe ein Programm gefunden mit dem ich JPEG-Bilder unter DOS verlustfrei drehen kann.
Das Programm heißt JPEGTRAN und kann hier runtergeladen werden
ftp://ftp.simtel.net/pub/simtelnet/msdo ... eg6b32.zip
Die Syntax lautet z.B.
jpegtran -rotate 90 pict1820.jpg pict182b.jpg
Der "Wermutstropfen" dabei ist das vorher ein Programm geladen werden muß, das den Speicher zur verfügung stellt.
Das Programm findet man hier:
http://www.delorie.com/djgpp/dl/ofc/sim ... pmi5b.zip/
Es heißt cwsdpmi
Ein erster Versuch war erfolgreich.
cwsdpmi.exe gestartet
anschließend mit jpegtran das Bild gedreht.
Zeit für die Drehung 14 Sekunden
jpegtran kann natürlich auch anders herum drehen, und ein paar Sachen mehr.
Gruß Frank
Ich habe ein Programm gefunden mit dem ich JPEG-Bilder unter DOS verlustfrei drehen kann.
Das Programm heißt JPEGTRAN und kann hier runtergeladen werden
ftp://ftp.simtel.net/pub/simtelnet/msdo ... eg6b32.zip
Die Syntax lautet z.B.
jpegtran -rotate 90 pict1820.jpg pict182b.jpg
Der "Wermutstropfen" dabei ist das vorher ein Programm geladen werden muß, das den Speicher zur verfügung stellt.
Das Programm findet man hier:
http://www.delorie.com/djgpp/dl/ofc/sim ... pmi5b.zip/
Es heißt cwsdpmi
Ein erster Versuch war erfolgreich.
cwsdpmi.exe gestartet
anschließend mit jpegtran das Bild gedreht.
Zeit für die Drehung 14 Sekunden
jpegtran kann natürlich auch anders herum drehen, und ein paar Sachen mehr.
Gruß Frank
CWSDPMI.EXE ist mir natürlich bekannt. Das ist ein "Treiber" für den 32-Bit-Mode (aka Protected Mode).
Dasmuß nicht "geladen" werden - den meisten Programmen, die es verwenden, reicht es, wenn das Teil im "Pfad" (PATH) liegt, die finden es dann und laden es selber vorher (und entladen es natürlich nach Benutzung).
Viele DOS-Programme, die den Protected Mode oder den 4G-Mode benutzen, greifen dafür auf CWSDPMI.EXE zurück. Es gint auch noch DOS4GW.EXE und PMODE.EXE. (Anmerkung: DPMI ist die Abkürzung für DOS Protected Mode Interface.)
Um 16-Bit (Real Mode) kann man ab dem 386er ja auch die 32-Bit-Register verwenden, aber die Segment-Register bleiben 16-Bit.
Der 4G-Mode funktioniert auch, wie der 16-Bit-Mode, nur daß man auch die Segmentregister auf 32-Bit erweitert und damit Zugriff auf den gesamten Speicher bis 4 GB hat. (Es ist so eine Art getrickster "Hybrid" zwischen Real Mode und Protected Mode.
Ich selber habe noch nie im 4G-Mode oder Protected Mode programmiert, daher ist mein Programm auf den HIMEM.SYS angewiesen, mit dem ich aber nur "indirekten" Zugriff auf den Speicher über 1 MB haben kann. Hätte ich direkten Zugriff, wäre mein Programm wesentlich schneller. Aber für direkten Zugriff bräuchte ich eben Speicheradressen, die größer sind. Und die kriege ich eben nur mit 4G-Mode oder PM.
Noch ne Anmerkung: Ich benutze PCX, weil das ein sehr einfaches Format ist und ich 100% verstehe, wie es funktioniert. Mit JPG kenne ich mich absolut nicht aus - daher kann ich JPG weder interpretieren, noch drehen oder so.
Mein Programm war daher nur eine kleine "Hilfe", es war nicht als "der Weisheit letzen Schluß" gedacht - hatte ich aber erwähnt.
Eigentlich wollte ich ja noch eine Größenveränderung des Bildes in das Programm einbauen, bin nur mit einigermaßen dringenden Projekten (für jemand anders) gerade sehr beschäftigt. Daß Du nun ein geeigneteres Programm gefunden hast (dachte mir schon, daß im riesigen Internet sowas irgendwo rumfliegen muß), entnehme ich, daß Du mein Programm nicht mehr brauchst. Da kann ich mir mit der Weiterentwicklung ja Zeit lassen.
Also, bis dann.
Dasmuß nicht "geladen" werden - den meisten Programmen, die es verwenden, reicht es, wenn das Teil im "Pfad" (PATH) liegt, die finden es dann und laden es selber vorher (und entladen es natürlich nach Benutzung).
Viele DOS-Programme, die den Protected Mode oder den 4G-Mode benutzen, greifen dafür auf CWSDPMI.EXE zurück. Es gint auch noch DOS4GW.EXE und PMODE.EXE. (Anmerkung: DPMI ist die Abkürzung für DOS Protected Mode Interface.)
Um 16-Bit (Real Mode) kann man ab dem 386er ja auch die 32-Bit-Register verwenden, aber die Segment-Register bleiben 16-Bit.
Der 4G-Mode funktioniert auch, wie der 16-Bit-Mode, nur daß man auch die Segmentregister auf 32-Bit erweitert und damit Zugriff auf den gesamten Speicher bis 4 GB hat. (Es ist so eine Art getrickster "Hybrid" zwischen Real Mode und Protected Mode.
Ich selber habe noch nie im 4G-Mode oder Protected Mode programmiert, daher ist mein Programm auf den HIMEM.SYS angewiesen, mit dem ich aber nur "indirekten" Zugriff auf den Speicher über 1 MB haben kann. Hätte ich direkten Zugriff, wäre mein Programm wesentlich schneller. Aber für direkten Zugriff bräuchte ich eben Speicheradressen, die größer sind. Und die kriege ich eben nur mit 4G-Mode oder PM.
Noch ne Anmerkung: Ich benutze PCX, weil das ein sehr einfaches Format ist und ich 100% verstehe, wie es funktioniert. Mit JPG kenne ich mich absolut nicht aus - daher kann ich JPG weder interpretieren, noch drehen oder so.
Mein Programm war daher nur eine kleine "Hilfe", es war nicht als "der Weisheit letzen Schluß" gedacht - hatte ich aber erwähnt.
Eigentlich wollte ich ja noch eine Größenveränderung des Bildes in das Programm einbauen, bin nur mit einigermaßen dringenden Projekten (für jemand anders) gerade sehr beschäftigt. Daß Du nun ein geeigneteres Programm gefunden hast (dachte mir schon, daß im riesigen Internet sowas irgendwo rumfliegen muß), entnehme ich, daß Du mein Programm nicht mehr brauchst. Da kann ich mir mit der Weiterentwicklung ja Zeit lassen.
Also, bis dann.
Das kann ich sehr gut verstehen. Ein befreundeter Programmierer hat einen Bildbetrachter für Geoworks (16-Bit) programmiert und diesbezüglich einen JPEG-Filter programmiert.DOSferatu hat geschrieben: Ich benutze PCX, weil das ein sehr einfaches Format ist und ich 100% verstehe, wie es funktioniert. Mit JPG kenne ich mich absolut nicht aus - daher kann ich JPG weder interpretieren, noch drehen oder so.
Obwohl ich ihn für den begabtesten Programmierer halte den wir für Geoworks noch haben hat er für die Entwicklung des Filters ca. 2 Jahre gebraucht weil Geos mit allen über 640 K Arbeitsspeicher nichts anfangen kann.
Er hatte auch mal einen Vortag über das JPEG-Format gehalten bei dem ich dabei gewesen bin, von daher habe ich eine "ungefähre" Vorstellung wie das Format funktioniert, und was das Problem dabei ist.
Das größte Problem dabei ist, daß du für eine 1 MB-JPEG-Grafik zum Entkomprimieren ein Vielfaches an Arbeitsspeicher (IMHO ca. 5 MB) benötigst, und du das bei 16-Bit einfach nicht hast.
Da mußt du sehr viel Tricksen mit Swap und auslagern und so, um das überhaupt hinzubekommen.
Bei der vielen Auslagerei leidet dann natürlich auch die Geschwindigkeit.
So hatte ich es auch verstanden.DOSferatu hat geschrieben: Mein Programm war daher nur eine kleine "Hilfe", es war nicht als "der Weisheit letzen Schluß" gedacht - hatte ich aber erwähnt.
Äh, ja. Ich hatte es auch erwähnt daß es nicht eilt.DOSferatu hat geschrieben: entnehme ich, daß Du mein Programm nicht mehr brauchst. Da kann ich mir mit der Weiterentwicklung ja Zeit lassen.
...aber ich habe da ein neues Problem für das ich eine Lösung brauche wo mir aber bestimmt auch andere weiterhelfen können.
Du hast schon so viel für mich getan. -> DANKE
Für das neue Problem mache ich ein neues Thema auf.
Viel Spaß beim Coden und Programmieren.DOSferatu hat geschrieben: Also, bis dann.
Gruß Frank