Riesige JPGs zusammenfügen -> Jpegjoin scheitert!

[Alan Tiedemann]

Hallo NG!

Ich habe hier ein (wohl eher seltenes) Problem. Ich habe mir von einer
Website Ausschnitte von antiken Landkarten heruntergeladen. Diese
Ausschnitte sind so angelegt, daß man sie nahtlos aneinanderfügen kann.

Leider scheitert Jpegjoin (Version 2002.01) bei mir ab einer bestimmten
Größe. Ich habe 6x8 Kacheln, je 3.952 x 3.616 Pixel. Gesamtgröße also
23.712 x 28.928 Pixel. Das ist so in etwa das "Standardformat" der
Karten ;-)

Um nicht ganz den Überblick zu verlieren, habe ich Jpegjoin erstmal
horizontale Streifen zusammensetzen lassen. Ich habe dann also 8 JPGs
mit je 23.712 x 3.616 Pixel. Die lassen sich sogar noch unfallfrei in
ACDsee ansehen und sind je ca. 15-20 MiB groß.

Wenn ich nun aber in Jpegjoin diese 8 Streifen zusammensetzen lassen
will, rödelt das Programm kurz auf der Platte, legt auch immer mal
wieder seine temporäre Datei ("tempcrop.jpg") an, hört dann aber
irgendwann *ohne* Fehlermeldung auf - und hat natürlich auch kein großes
JPG erzeugt :-( Die Hälfte schafft er, vier solcher Streifen kann er
problemlos zusammensetzen.

Woran kann das liegen? Mein Rechner hat 1,25 GiB RAM, auf der Platte
sind noch ca. 5 GiB frei, das Swapfile wird nicht größer als 640 MiB.

Gibt es alternativ ein anderes Tool, um so große JPGs verlustfrei
zusammenzusetzen? Darf auch gerne eine "Kommandozeilenversion" sein,
sollte aber unter Win2k laufen - Linux steht hier nicht zur Verfügung.

Schonmal vielen Dank ;-)

Alan

[Holger Kaczmarek]

Post by Alan Tiedemann
ACDsee ansehen und sind je ca. 15-20 MiB groß.

(M)en (i)n (B)lack?

/jpgs zusammensetzen... gesnippt/

Hi Alan,

also, mit den von Dir geforderten Proggis kann ich Dir leider nicht
weiterhelfen. Aber gestatte mir die Frage, warum Du dies nicht mit einem
guten "normalen" Grafikproggi machst, und manuell ein wenig Hand anlegst?

Desweiteren würde ich gerne wissen, wo man solche Karten runterlädt, ist das
ein öffentlicher Server?

Gruß
Holger

[Alan Tiedemann]

Post by Holger Kaczmarek

Post by Alan Tiedemann
ACDsee ansehen und sind je ca. 15-20 MiB groß.

(M)en (i)n (B)lack?

MibiBytes. 2^20. Offizielle Bezeichnung für 2er-Potenzen. Siehe
<http://physics.nist.gov/cuu/Units/binary.html>.

Post by Holger Kaczmarek
/jpgs zusammensetzen... gesnippt/
also, mit den von Dir geforderten Proggis kann ich Dir leider nicht
weiterhelfen. Aber gestatte mir die Frage, warum Du dies nicht mit einem
guten "normalen" Grafikproggi machst, und manuell ein wenig Hand anlegst?

Aus dem einfachen Grund, daß "normale" Grafikproggis beim Laden und
Zusammensetzen von JPGs diese hinterher neu komprimieren - was *immer*
einen Qualitätsverlust beinhaltet. Außerdem reserviert Corel Photo Paint
schon nach etwa einem Drittel geladener Kacheln 2 GiB Speicher, und dann
wird das Arbeiten selbst mit 1,25 GiB "echtem" RAM zur Qual. Nein, ich
möchte nicht ausprobieren was passiert wenn ich *alle* 48 Kacheln lade,
da semmelt mir dann wahrscheinlich der Rechner ab...

Post by Holger Kaczmarek
Desweiteren würde ich gerne wissen, wo man solche Karten runterlädt, ist das
ein öffentlicher Server?

Ja, ist es: <http://www.davidrumsey.com/view.html> - man braucht aber
ein bißchen Übung oder ein geeignetes Tool (hab ich mir in Delphi selber
geschrieben), bevor man in der Lage ist, nahtlose "Kacheln" herunterzuladen.

Ich habe jetzt auch GraphicsMagick ausprobiert (die Kommandozeile zu
basteln war nicht *ganz* einfach), aber das Tool habe ich nach einer
Stunde abgewürgt - da hatte es schon eine 4 GiB große Datei in meinen
Temp-Ordner geschrieben und sich ca. 768 MiB Swapfile (also insgesamt 2
GiB Speicher) gekrallt, aber ansonsten nicht viel produziert - und die
Platte war voll :-(

Gibt es denn kein Tool, das einfach JPGs "aneinanderhängen" kann?
Meinetwegen auch "nur" zeilenweise untereinander, nicht nebeneinander.

Alan

[Thomas Richard]

Hallo,

Post by Alan Tiedemann
Woran kann das liegen? Mein Rechner hat 1,25 GiB RAM, auf der Platte
sind noch ca. 5 GiB frei, das Swapfile wird nicht größer als 640 MiB.

Das ist dann wohl das Problem.
Die offenen JPEGs geben zusammen 23712 x 28928 x 3 (RGB?) = 1,96GB

Da dürfte es mit dem Swappen irgendwo hapern. Wenn obiges Programm die
Bilder tatsächlich ohne Neukomprimierung zusammensetzt (was durch
teilbarkeit durch 8 theoretisch möglich ist), sollte es allerdings mit
weniger Speicher auskommen.

Post by Alan Tiedemann
Gibt es alternativ ein anderes Tool, um so große JPGs verlustfrei
zusammenzusetzen? Darf auch gerne eine "Kommandozeilenversion" sein,
sollte aber unter Win2k laufen - Linux steht hier nicht zur Verfügung.

Sag doh mal wie groß so ein JPEG komprimiert ist, dann sag ich dir, ob
du dir über die neukomprimierung sorgen zu machen brauchst. Bei
Vektorisierten Karten ist das nämlich ein denkbar schlechtes Format.
Aber es geht ja wohl um Scans.

MfG

Thomas

[Alan Tiedemann]

Post by Thomas Richard
Hallo,

"Hallo"? Mail? Nein, Usenet - bitte schreib eine Attribution Line, danke ;-)

Post by Thomas Richard

Post by Alan Tiedemann
Woran kann das liegen? Mein Rechner hat 1,25 GiB RAM, auf der Platte
sind noch ca. 5 GiB frei, das Swapfile wird nicht größer als 640 MiB.

Das ist dann wohl das Problem.
Die offenen JPEGs geben zusammen 23712 x 28928 x 3 (RGB?) = 1,96GB

Ja... und? Wozu muß man die dekomprimieren? Ich dachte Jpegjoin fügt die
*ohne* Neukomprimierung aneinander - sonst geht doch der Witz bei der
Sache verloren.

Post by Thomas Richard
Da dürfte es mit dem Swappen irgendwo hapern. Wenn obiges Programm die
Bilder tatsächlich ohne Neukomprimierung zusammensetzt (was durch
teilbarkeit durch 8 theoretisch möglich ist), sollte es allerdings mit
weniger Speicher auskommen.

Insgesamt sind die JPGs gerade mal 143 MiB groß. Das sollte man doch bei
1,25 GiB RAM quasi im Plattencache zusammensetzen können ;-)

Post by Thomas Richard

Post by Alan Tiedemann
Gibt es alternativ ein anderes Tool, um so große JPGs verlustfrei
zusammenzusetzen? Darf auch gerne eine "Kommandozeilenversion" sein,
sollte aber unter Win2k laufen - Linux steht hier nicht zur Verfügung.

Sag doh mal wie groß so ein JPEG komprimiert ist, dann sag ich dir, ob
du dir über die neukomprimierung sorgen zu machen brauchst.

Sorry, das will ich nicht. Ich schneide auch meine 8-GiB-MPEG2-Videos
verlustfrei, warum soll ich da bei sowas "Profanem" wie ein paar JPEGs
neu komprimieren müssen?

Der Komprimierungsfaktor liegt übrigens bei ca. 1:14, Artefakte sind
also schon jetzt an einigen Stellen spürbar.

Post by Thomas Richard
Bei Vektorisierten Karten ist das nämlich ein denkbar schlechtes Format.
Aber es geht ja wohl um Scans.

So ist es. Im Jahre 1810 hat man sowas noch per Hand gezeichnet bzw. in
Druckplatten geritzt ;-)

Immerhin konnte ich die Karte von Guatemala von 1733 am Stück
runterladen, aber mit 8.376 x 5.492 Pixeln und 12 MiB ist die ja auch
lächerlich winzig *g*

Alan

[Thomas Richard]

Post by Alan Tiedemann

Post by Thomas Richard
Hallo,

"Hallo"? Mail? Nein, Usenet - bitte schreib eine Attribution Line, danke ;-)

besser?

Post by Alan Tiedemann

Post by Thomas Richard

Post by Alan Tiedemann
Woran kann das liegen? Mein Rechner hat 1,25 GiB RAM, auf der Platte
sind noch ca. 5 GiB frei, das Swapfile wird nicht größer als 640 MiB.

Das ist dann wohl das Problem.
Die offenen JPEGs geben zusammen 23712 x 28928 x 3 (RGB?) = 1,96GB

Ja... und? Wozu muß man die dekomprimieren? Ich dachte Jpegjoin fügt die
*ohne* Neukomprimierung aneinander - sonst geht doch der Witz bei der
Sache verloren.

Ja aber nur wenn sie durch 8 teilbare Pixelbreiten haben, ansonsten
würde es Problematisch.

Post by Alan Tiedemann

Post by Thomas Richard
Da dürfte es mit dem Swappen irgendwo hapern. Wenn obiges Programm die
Bilder tatsächlich ohne Neukomprimierung zusammensetzt (was durch
teilbarkeit durch 8 theoretisch möglich ist), sollte es allerdings mit
weniger Speicher auskommen.

Insgesamt sind die JPGs gerade mal 143 MiB groß. Das sollte man doch bei
1,25 GiB RAM quasi im Plattencache zusammensetzen können ;-)

Post by Thomas Richard

Post by Alan Tiedemann
Gibt es alternativ ein anderes Tool, um so große JPGs verlustfrei
zusammenzusetzen? Darf auch gerne eine "Kommandozeilenversion" sein,
sollte aber unter Win2k laufen - Linux steht hier nicht zur Verfügung.

Sag doh mal wie groß so ein JPEG komprimiert ist, dann sag ich dir, ob
du dir über die neukomprimierung sorgen zu machen brauchst.

Sorry, das will ich nicht. Ich schneide auch meine 8-GiB-MPEG2-Videos
verlustfrei, warum soll ich da bei sowas "Profanem" wie ein paar JPEGs
neu komprimieren müssen?

Weil es da um andere Auflösungen geht? wäre dein 8GB MPEG2 einne 0,2
Sekunden Sequenz aus 4 Bildern, würdest du sicherlich auch
neukomprimieren müssen. Was du da vergleichst hat nicht viel miteinander
zu tun.

Post by Alan Tiedemann
Der Komprimierungsfaktor liegt übrigens bei ca. 1:14, Artefakte sind
also schon jetzt an einigen Stellen spürbar.

Na Spürbar ist doch ok,, solange man sie nicht sieht ;-)

Post by Alan Tiedemann

Post by Thomas Richard
Bei Vektorisierten Karten ist das nämlich ein denkbar schlechtes Format.
Aber es geht ja wohl um Scans.

So ist es. Im Jahre 1810 hat man sowas noch per Hand gezeichnet bzw. in
Druckplatten geritzt ;-)

Obiges gilt aber auch für Strichzeichnungen bzw. alle Bilder mit extrem
hohen Kontrasten.

Wenn ich die anderen Postings richtig in Erinnerung habe, dann willst du
23712 Pixel in RGB by 8 Bit Farbtiefe je Kanal auf einen 600dpi Drucker
auf 2m Breite bringen und hast Angst Daten durch Neukomprimierung zu
verlieren?

Wenn du die 8 Bit erhalten willst (wenn nicht ist die ganze Überlegung
ja auch wieder für die Füsse), so brauchst du pro Zoll gerade mal 75
Pixel. Die könnte dann ein 600dpi Drucker in 256 Stufen zu Papier
bringen. Allerdings bräuchte er dann eine Fläche von über 8 m auf knapp
10 m.

Du sparst definitv am falschen Ende.

MfG

Thomas

Ich würde mal einen der Flicken auf 300 dpi (was bei deinen 2m die
Effektive Auflösung wäre und einmal mit 75dpi ausgeben lassen. Dann
kannst du ja mal schaun was in der 6qm Version noch übrig bleibt wenn
der Drucker mit 600 dpi zu Werke geht.

MfG

Thomas

[Alan Tiedemann]

Post by Thomas Richard

Post by Alan Tiedemann
"Hallo"? Mail? Nein, Usenet - bitte schreib eine Attribution Line, danke ;-)

besser?

Dankeschön ;-)

Post by Thomas Richard

Post by Alan Tiedemann
Ja... und? Wozu muß man die dekomprimieren? Ich dachte Jpegjoin fügt die
*ohne* Neukomprimierung aneinander - sonst geht doch der Witz bei der
Sache verloren.

Ja aber nur wenn sie durch 8 teilbare Pixelbreiten haben, ansonsten
würde es Problematisch.

Die sind durch 16 teilbar (mein "Downloader" ist entsprechend
programmiert), und die Anzeige in Jpegjoin bestätigt das auch.

Es gibt übrigens 1x1, 2x2, 1x2 und 2x1 (jeweils mit 8 multiplizieren)
als gültige Rastergrößen bei JPG.

Post by Thomas Richard

Post by Alan Tiedemann

Post by Thomas Richard
Sag doh mal wie groß so ein JPEG komprimiert ist, dann sag ich dir, ob
du dir über die neukomprimierung sorgen zu machen brauchst.

Sorry, das will ich nicht. Ich schneide auch meine 8-GiB-MPEG2-Videos
verlustfrei, warum soll ich da bei sowas "Profanem" wie ein paar JPEGs
neu komprimieren müssen?

Weil es da um andere Auflösungen geht? wäre dein 8GB MPEG2 einne 0,2
Sekunden Sequenz aus 4 Bildern, würdest du sicherlich auch
neukomprimieren müssen. Was du da vergleichst hat nicht viel miteinander
zu tun.

Also ob ich nun MPGs (wo man GOPs, Audiostreams und anderes
berücksichtigen muß) verlustfrei *hintereinanderhängt* oder JPGs nahtlos
*aneinander* hängt, dürfte ja nun wirklich keinen großen Unterschied machen.

Post by Thomas Richard

Post by Alan Tiedemann
Der Komprimierungsfaktor liegt übrigens bei ca. 1:14, Artefakte sind
also schon jetzt an einigen Stellen spürbar.

Na Spürbar ist doch ok,, solange man sie nicht sieht ;-)

Hmpf ;-)

Post by Thomas Richard

Post by Alan Tiedemann

Post by Thomas Richard
Bei Vektorisierten Karten ist das nämlich ein denkbar schlechtes Format.
Aber es geht ja wohl um Scans.

So ist es. Im Jahre 1810 hat man sowas noch per Hand gezeichnet bzw. in
Druckplatten geritzt ;-)

Obiges gilt aber auch für Strichzeichnungen bzw. alle Bilder mit extrem
hohen Kontrasten.

Naja, das Papier hat halt auch eine schöne Textur, und es ist dadurch
schon sehr "analog". Die Beschriftung der Karte ist übrigens einwandfrei
lesbar und ohne JPG-Artefakte.

Post by Thomas Richard
Wenn ich die anderen Postings richtig in Erinnerung habe, dann willst du
23712 Pixel in RGB by 8 Bit Farbtiefe je Kanal auf einen 600dpi Drucker
auf 2m Breite bringen und hast Angst Daten durch Neukomprimierung zu
verlieren?

Ich will es *dieses Jahr* darauf ausdrucken. Ich möchte mir aber
natürlich nicht die Qualität für die Zukunft versauen - und auf dem
Server liegen noch fast 9000 weitere Karten, da möchte ich einfach
einmal eine vernünftige Vorgehensweise finden.

Ich habe auch schon ca. 1,5 TiB an Videos verlustfrei geschnitten, da
habe ich den Ehrgeiz, das auch bei Standbildern hinzukriegen ;-)

Post by Thomas Richard
Wenn du die 8 Bit erhalten willst (wenn nicht ist die ganze Überlegung
ja auch wieder für die Füsse), so brauchst du pro Zoll gerade mal 75
Pixel. Die könnte dann ein 600dpi Drucker in 256 Stufen zu Papier
bringen. Allerdings bräuchte er dann eine Fläche von über 8 m auf knapp
10 m.
Du sparst definitv am falschen Ende.

Es geht mir einfach ums Prinzip. Es muß doch möglich sein, sowas
zusammenzusetzen ohne es neu zu komprimieren.

Zumal ich das Zeugs weder in den (einfachen!) Bildbearbeiter von ACDsee
reinkriege noch in Corel Photo Paint. Die Programme machen trotz meiner
nicht gerade knappen Speicherausstattung schon bei der Hälfte dicke Backen.

Ich werde mal bei der Druckerei anfragen wegen der PDF-Geschichte.

Alan

[Thomas Richard]

Post by Alan Tiedemann
Die sind durch 16 teilbar (mein "Downloader" ist entsprechend
programmiert), und die Anzeige in Jpegjoin bestätigt das auch.
Es gibt übrigens 1x1, 2x2, 1x2 und 2x1 (jeweils mit 8 multiplizieren)
als gültige Rastergrößen bei JPG.

Was die Probleme des Trennens aber nur vergrößert da dann nur alle 16
Pixel ein Schnitt möglich ist, ohne die Rand Kacheln neukompriomierern
zu müssen und dabei alle andern zu verschieben und damit den JPEG Gau
für maximale Verluste bei minimalen Bildveränderungen zu provozieren.

Post by Alan Tiedemann

Post by Thomas Richard

Post by Alan Tiedemann

Post by Thomas Richard
Sag doh mal wie groß so ein JPEG komprimiert ist, dann sag ich dir, ob
du dir über die neukomprimierung sorgen zu machen brauchst.

Sorry, das will ich nicht. Ich schneide auch meine 8-GiB-MPEG2-Videos
verlustfrei, warum soll ich da bei sowas "Profanem" wie ein paar JPEGs
neu komprimieren müssen?

Weil es da um andere Auflösungen geht? wäre dein 8GB MPEG2 einne 0,2
Sekunden Sequenz aus 4 Bildern, würdest du sicherlich auch
neukomprimieren müssen. Was du da vergleichst hat nicht viel miteinander
zu tun.

Also ob ich nun MPGs (wo man GOPs, Audiostreams und anderes
berücksichtigen muß) verlustfrei *hintereinanderhängt* oder JPGs nahtlos
*aneinander* hängt, dürfte ja nun wirklich keinen großen Unterschied machen.

Du kannst in eiem Minicooper 10t Sand an einem Tag von A nach B
Transportieren, aber keien Findling vom selben Gewicht, auch nicht in
aller Zeit dieser Welt, wenn du ihn nicht 'umspeichern' AKA mahlen,
shreddern, sprengen willst.
Jetzt klarer?
Es geht um den Happen, der am Stück zu verarbeiten ist.
Das sind in deinem Fall riesen Brocken, beim Film jede Menge Sandkörner.

Post by Alan Tiedemann
Ich will es *dieses Jahr* darauf ausdrucken. Ich möchte mir aber
natürlich nicht die Qualität für die Zukunft versauen - und auf dem
Server liegen noch fast 9000 weitere Karten, da möchte ich einfach
einmal eine vernünftige Vorgehensweise finden.
Ich habe auch schon ca. 1,5 TiB an Videos verlustfrei geschnitten, da
habe ich den Ehrgeiz, das auch bei Standbildern hinzukriegen ;-)

Ohh, wenn's um Ehrgeiz geht, stossen rationale Argumente ja gerne mal
schnell und endgültig an Ihre Grenzen ;-)

Post by Alan Tiedemann

Post by Thomas Richard
Wenn du die 8 Bit erhalten willst (wenn nicht ist die ganze Überlegung
ja auch wieder für die Füsse), so brauchst du pro Zoll gerade mal 75
Pixel. Die könnte dann ein 600dpi Drucker in 256 Stufen zu Papier
bringen. Allerdings bräuchte er dann eine Fläche von über 8 m auf knapp
10 m.
Du sparst definitv am falschen Ende.

Es geht mir einfach ums Prinzip. Es muß doch möglich sein, sowas
zusammenzusetzen ohne es neu zu komprimieren.
Zumal ich das Zeugs weder in den (einfachen!) Bildbearbeiter von ACDsee
reinkriege noch in Corel Photo Paint. Die Programme machen trotz meiner
nicht gerade knappen Speicherausstattung schon bei der Hälfte dicke Backen.
Ich werde mal bei der Druckerei anfragen wegen der PDF-Geschichte.

Ich würde mir mal Ecken herauskopieren (die vier um einen Kreuzungspunkt
von 4 Stücken und sie bei Vielfachen von acht zusammensetzen und schauen
ws da beim neukomprimieren tatsächlich verloren geht. Wenn Bilder erst
einmal JPEG komprimiert aren ist das schlimmste eigentlich passiert.
Nachträgliche Verluste treten nur bei ganz niedrigen Qualitäten (wie sie
im Internet eher die REgel sind) auf. Bei mittleren bis hohen
Qualitätstufen ist das eher zu vernachlässigen.

Für die Zukunft würde ich die Einzelteile so lassen wie sie sind, besser
werden sie eh nicht.
In früheren Photoshop Versionen gab es einen Importfilter, der bei
punktuellen Korrekturen an großen Tiffs (übersehene Flusen in Scanns)
ein auschnittweises Öffnen undn zurückschreiben des Bildes zulies, so
brauchte man für Korrekturen an ein paar Bytes nicht zig oder hunderte
von Mb durchs Netz zu Pumpen. Ähnliches nur Umgekehrt gibt es vielleicht
auch irgendwann für deine Karten oder gestitchte Bilder, die mehr
enthalten als man auf einen Blick erfassen kann.

Im Prinzip hat Thomas Kaiser recht, jedes Layoutprogramm ermöglicht im
Prinzip das Pixelgenaue platzieren solcher Brocken, ohne wirklich ans
Bild zu müssen.

Wsa du willst ist ja eher eien Collage und das ist nicht zwangsläufig
das Metier eiener Bildbearbeitung, sondern das eines Layoutprogramms.

MfG

Thomas

[Thomas Kaiser]

Thomas Richard schrieb am 23.12.2003 23:11 Uhr in

Post by Thomas Richard
Wenn du die 8 Bit erhalten willst (wenn nicht ist die ganze Überlegung
ja auch wieder für die Füsse), so brauchst du pro Zoll gerade mal 75
Pixel. Die könnte dann ein 600dpi Drucker in 256 Stufen zu Papier
bringen.

Deine Rechnung mit 600 dpi <--> 1 Bit Farbtiefe und 75 dpi <--> 8 Bit
Farbtiefe geht aber nur bei autotypischen Rastern auf. Bei guten
FM-Rasterizern kann eine höhere effektive Auflösung durchaus zu mehr
Detailzeichnung führen.

Allerdings konnte ich bei meinen Tests (Jahre her) jenseits 150 dpi
Vorlagenauflösung keinerlei optische Verbesserung mehr feststellen
(allerdings nicht HP sondern Epson)

Gruss,

Thomas

[Thomas Richard]

Post by Thomas Kaiser
Thomas Richard schrieb am 23.12.2003 23:11 Uhr in

Post by Thomas Richard
Wenn du die 8 Bit erhalten willst (wenn nicht ist die ganze Überlegung
ja auch wieder für die Füsse), so brauchst du pro Zoll gerade mal 75
Pixel. Die könnte dann ein 600dpi Drucker in 256 Stufen zu Papier
bringen.

Deine Rechnung mit 600 dpi <--> 1 Bit Farbtiefe und 75 dpi <--> 8 Bit
Farbtiefe geht aber nur bei autotypischen Rastern auf. Bei guten
FM-Rasterizern kann eine höhere effektive Auflösung durchaus zu mehr
Detailzeichnung führen.

Fürwar wahr.
Nichts desto trotz ist der Kardinalfehler das 600dpi Drucker 256 Farben
mit dieser Auflösung hinbekommen vorhanden. Bei den heute üblichenn FM
Rastern mag der Faktor nicht 8 sein, aber 2 ist er sicherlich auch nicht
;-)

Post by Thomas Kaiser
Allerdings konnte ich bei meinen Tests (Jahre her) jenseits 150 dpi
Vorlagenauflösung keinerlei optische Verbesserung mehr feststellen
(allerdings nicht HP sondern Epson)

yepp, geht mir auch heute noch genauso, ausser Bitmapgrafiken mit bösen
diagonalen, die offenbaren jedes fehlende bisschen an Auflösung sofort.

Das würde für den konkreten Fall aber immer noch bedeuten das er auf dem
600 dpi Drucker 4 auf 5 Meter mit diesen Daten drucken kann, deswegen
sehe ich seine Angst um Kompressionsverluste nicht so dramatisch.

Ah, bevor ich's vergesse: Frohes Fest

Und nochwas... kann es sein das deine Quellenangabe (Oktoberausgabe
Linuxmagazin) bzgl. Webdav nicht stimmt? Nachdem die Spezis mir jetzt 2x
eine falsche Ausgabe geschickt haben, find ich nichts wirklich
erhellendes.

MfG

Thomas

Post by Thomas Kaiser
Gruss,
Thomas

[Andreas Hollmann]

Post by Alan Tiedemann
So ist es. Im Jahre 1810 hat man sowas noch per Hand gezeichnet bzw. in
Druckplatten geritzt ;-)

Ach ja - stimmt. Das GIF-Format wurde ja erst 1820 erfunden ;-)

Andreas

[Leo Hafner]

Hallo Alan,

Post by Alan Tiedemann
Leider scheitert Jpegjoin (Version 2002.01) bei mir ab einer bestimmten
Größe. Ich habe 6x8 Kacheln, je 3.952 x 3.616 Pixel. Gesamtgröße also
23.712 x 28.928 Pixel. Das ist so in etwa das "Standardformat" der
Karten ;-)

ca. 25000 Pixel an einer Seitenlänge ergeben bei einer Auflösung von
300dpi eine Größe von über 2 x 2 Metern!
Du solltest dir dein Endformat überlegen und das Ausgabegerät bevor du
womöglich unnötig mit solchen Megadateien herumwerkst.
Wenn du das festgelegt hast, solltest du die Originalteile mit einem
üblichen Programm erst herunterrechnen, zusammenfügen und dann
verlustfrei komprimiert - z.B. als TIF LZW - abspeichern.

Die unbarbeiteten Teile kannst du dir ja aufbehalten, für Zeiten, in
denen die Bearbeitung weniger Problem sein wird ...

Grüße, Leo

[Alan Tiedemann]

Post by Leo Hafner
Hallo Alan,

Post by Alan Tiedemann
Leider scheitert Jpegjoin (Version 2002.01) bei mir ab einer bestimmten
Größe. Ich habe 6x8 Kacheln, je 3.952 x 3.616 Pixel. Gesamtgröße also
23.712 x 28.928 Pixel. Das ist so in etwa das "Standardformat" der
Karten ;-)

ca. 25000 Pixel an einer Seitenlänge ergeben bei einer Auflösung von
300dpi eine Größe von über 2 x 2 Metern!

Ja, so in etwa wollte ich das auch haben ;-) Soll eigentlich eine Karte
werden, die man sich an die Wand hängt.

Post by Leo Hafner
Du solltest dir dein Endformat überlegen und das Ausgabegerät bevor du
womöglich unnötig mit solchen Megadateien herumwerkst.

Es geht mir ums Prinzip.

Post by Leo Hafner
Wenn du das festgelegt hast, solltest du die Originalteile mit einem
üblichen Programm erst herunterrechnen, zusammenfügen und dann
verlustfrei komprimiert - z.B. als TIF LZW - abspeichern.

Warum ausgerechnet TIF? Ich wollte jetzt eigentlich nicht 2 GiB Platz
für etwas belegen, das nur 140 MiB groß ist.

Post by Leo Hafner
Die unbarbeiteten Teile kannst du dir ja aufbehalten, für Zeiten, in
denen die Bearbeitung weniger Problem sein wird ...

Irgendjemand muß diese JPGs ja mal erzeugt haben - hat der die per Hand
geschnitzt? Und warum belegen die Programme, die ja angeblich "ohne
Neukomprimierung" die JPGs zusammensetzen, zwischen 2 und 4 GiB
temporären Speicher?

Alan

[Stefan Lagotzki]

Hallo Alan,

die Karte muss ja irgendwann auf das Papier und in einer
Richtung wirst Du das Poster wohl zusammenkleben muessen.
Oder hast Du einen Plotter, der das Papier 2 Meter breit
*und* 2 Meter lang bedrucken kann? Also ist es wahr-
scheinlich besser, zwei Grafikdateien mit jeweils ca.
1m x 2m anzufertigen.

Da Du auch ImageMagick erwaehnt hattest: in der Doku zu
diesem Programm wird nicht behauptet, dass die Bilder ohne
eine Neukomprimierung zusammengesetzt werden. Es ist die
Arbeitsweise dieses Programms, die Bilddaten unkomprimiert
im RAM zu halten. Und wenn Du mit solchen Datenmengen
umgehen musst, dann ist eben mehr RAM (oder swap-Speicher)
notwendig.

Stefan

.

[Alan Tiedemann]

Post by Stefan Lagotzki
die Karte muss ja irgendwann auf das Papier und in einer
Richtung wirst Du das Poster wohl zusammenkleben muessen.

<http://www.digitale-plakate.de/digitale-plakate/index.php>

Post by Stefan Lagotzki
Oder hast Du einen Plotter, der das Papier 2 Meter breit
*und* 2 Meter lang bedrucken kann? Also ist es wahr-
scheinlich besser, zwei Grafikdateien mit jeweils ca.
1m x 2m anzufertigen.

Nö. Das soll, wenn, dann die Druckerei machen. Die wissen schon, wie sie
was haben wollen.

Post by Stefan Lagotzki
Da Du auch ImageMagick erwaehnt hattest: in der Doku zu
diesem Programm wird nicht behauptet, dass die Bilder ohne
eine Neukomprimierung zusammengesetzt werden.

Stimmt, in der Doku steht eigentlich sowieso *überhaupt nichts* zu dem
Programm. Zumindest habe ich keine Doku entdecken können, die dem Namen
gerecht wird :-(

Post by Stefan Lagotzki
Es ist die
Arbeitsweise dieses Programms, die Bilddaten unkomprimiert
im RAM zu halten.

Das wären dann 2 GiB. Warum zum Henker belegt es dann 2 GiB RAM und 4
GiB Temporäre Dateien und kommt nicht zu Potte?

Post by Stefan Lagotzki
Und wenn Du mit solchen Datenmengen
umgehen musst, dann ist eben mehr RAM (oder swap-Speicher)
notwendig.

Okay, dann werde ich es nochmal mit Jpegjoin versuchen und vorher meine
Platte leerräumen. Das muß doch zu schaffen sein! Irgendjemand hat die
Bilder ja auch mal erzeugt, die Datei wird er ja nicht eingetippt haben.

Alan

[Thomas Kaiser]

Alan Tiedemann schrieb am 23.12.2003 13:24 Uhr in

Post by Alan Tiedemann

hast Du einen Plotter, der das Papier 2 Meter breit *und* 2 Meter lang
bedrucken kann? Also ist es wahr- scheinlich besser, zwei Grafikdateien
mit jeweils ca. 1m x 2m anzufertigen.

Manche Druckereien und Dienstleister haben durchaus solche Geräte vor
Ort -- auch wenn deren Qualität meistens nicht mal 50 dpi Bildauflösung
rechtfertigen würde, weil die Rasterung viel zu grob ausfällt.
Wahrscheinlich werden sie also doch irgendwie anstückeln...

Post by Alan Tiedemann
Nö. Das soll, wenn, dann die Druckerei machen. Die wissen schon, wie sie
was haben wollen.

Eine Alternative wäre noch, den einzelnen JFIF-Dateien ein EPS- oder
PDF-Mäntelchen überzustülpen (mit den richtigen Werkzeugen *ohne* erneutes
De-/Komprimieren möglich) und diese dann aneinanderzureihen? Du kannst ja
mal fragen, ob sie eine elektronische Bogenmontage-Software vor Ort haben --
die sollte das aus dem Stegreif heraus können...

Ich hatte vor drei Jahren mal mit relativ wenig Aufwand sowas gebastelt für
die Ausgabe auf Xeikon-Druckmaschinen (Zusammenfügen und anschl. Zerstückeln
auf Druckbahnbreite mit Berücksichtigung von Überlappungen, etc.)

[ImageMagick]

Post by Alan Tiedemann
Warum zum Henker belegt es dann 2 GiB RAM und 4 GiB Temporäre Dateien und
kommt nicht zu Potte?

Vielleicht weil Du eine Version benutzt, die intern mit 16 Bit rechnet
(Standard)? Ich habe mir für speicherintensive Geschichten früher immer noch
eine Version nebenher kompiliert, die nur mit 8 Bit Farbtiefe zugange war --
wie das heute ist (also ob es dafür evtl. sogar einen Schalter gibt) weiß
ich aber nicht...

Gruss,

Thomas

[Alan Tiedemann]

Post by Thomas Kaiser
Alan Tiedemann schrieb am 23.12.2003 13:24 Uhr in

[Mach den Roman mal bitte kürzer - Danke :-)]

Post by Thomas Kaiser
Manche Druckereien und Dienstleister haben durchaus solche Geräte vor
Ort -- auch wenn deren Qualität meistens nicht mal 50 dpi Bildauflösung
rechtfertigen würde, weil die Rasterung viel zu grob ausfällt.
Wahrscheinlich werden sie also doch irgendwie anstückeln...

Die Druckerei arbeitet mit einem 600dpi HP-Plotter. Die Qualität ist
sehr gut, wie ich schon bei einem Kunden von mir gesehen habe (der hat
ein ähnliches Gerät für Bauzeichnungen, druckt aber gelegentlich auch
mal kleinere (A3/A2) Fotos aus).

Post by Thomas Kaiser

Post by Alan Tiedemann
Nö. Das soll, wenn, dann die Druckerei machen. Die wissen schon, wie sie
was haben wollen.

Eine Alternative wäre noch, den einzelnen JFIF-Dateien ein EPS- oder
PDF-Mäntelchen überzustülpen (mit den richtigen Werkzeugen *ohne* erneutes
De-/Komprimieren möglich) und diese dann aneinanderzureihen? Du kannst ja
mal fragen, ob sie eine elektronische Bogenmontage-Software vor Ort haben --
die sollte das aus dem Stegreif heraus können...

Danach werde ich mal fragen, danke für den Tip!

Post by Thomas Kaiser

Post by Alan Tiedemann
Warum zum Henker belegt es dann 2 GiB RAM und 4 GiB Temporäre Dateien und
kommt nicht zu Potte?

Vielleicht weil Du eine Version benutzt, die intern mit 16 Bit rechnet
(Standard)?

Nein, ich habe schon absichtlich nur die 8-Bit-Variante runtergeladen.

Post by Thomas Kaiser
Ich habe mir für speicherintensive Geschichten früher immer noch
eine Version nebenher kompiliert, die nur mit 8 Bit Farbtiefe zugange war --
wie das heute ist (also ob es dafür evtl. sogar einen Schalter gibt) weiß
ich aber nicht...

Es gibt zwei Versionen, eine für 8 Bit, eine für 16. Ich habe die
8-Bit-Version.

GraphicsMagick scheint es ja aber sowieso nicht ohne Rekompression zu
können, also laß ich das wohl bleiben...

Danke auf jeden Fall für den Vorschlag mit dem PDF, ich werde mal in der
Druckerei anfragen!

Alan

[Peter Vratny]

Post by Alan Tiedemann
Stimmt, in der Doku steht eigentlich sowieso *überhaupt nichts* zu dem
Programm. Zumindest habe ich keine Doku entdecken können, die dem Namen
gerecht wird :-(

loki:~$ man ImageMagick | wc -l
2537

2537 Zeilen Erklärungen in der Hauptdatei!
rtfm!

SEE ALSO
animate(1), display(1), animate(1), display(1), identify(1),
import(1),
montage(1), mogrify(1), composite(1)

_Wieviel_ Doku hättest du denn gerne?
Scheiß OpenSource, nix in Hochglanz, alles muss man sich selbst suchen....
http://www.imagemagick.org und google sind btw auch schon erfunden.


cnr,
Peter

[Alan Tiedemann]

Post by Peter Vratny

Post by Alan Tiedemann
Stimmt, in der Doku steht eigentlich sowieso *überhaupt nichts* zu dem
Programm. Zumindest habe ich keine Doku entdecken können, die dem Namen
gerecht wird :-(

loki:~$ man ImageMagick | wc -l
2537
2537 Zeilen Erklärungen in der Hauptdatei!
rtfm!

man Windows.

Post by Peter Vratny
SEE ALSO
animate(1), display(1), animate(1), display(1), identify(1),
import(1),
montage(1), mogrify(1), composite(1)
_Wieviel_ Doku hättest du denn gerne?

Bei der Windows-Version ist nix dabei. gm -help bringt eine klitzekleine
Übersicht:

C:\>gm -help
Version: GraphicsMagick 1.0.4 December 6, 2003 Q8
http://www.GraphicsMagick.org/

Copyright: Copyright (C) 2002, 2003 GraphicsMagick Group

Usage: gm command [options ...]

Where options include:
-version print version information
animate [options] run the "animate" utility
composite [options] run the "composite" utility
conjure [options] run the "conjure" utility
convert [options] run the "convert" utility
display [options] run the "display" utility
identify [options] run the "identify" utility
import [options] run the "import" utility
mogrify [options] run the "mogrify" utility
montage [options] run the "montage" utility

gm montage gibt zwei Bildschirmseiten mit knappsten Aussagen zu den
möglichen Parametern. Auszug:

-gamma value level of gamma correction
-geometry geometry preferred tile and border sizes
-gravity direction which direction to gravitate towards
-green-primary point chomaticity green primary point
-interlace type None, Line, Plane, or Partition
-help print program options
-label name assign a label to an image

Mehr gibt's nicht. Die "Onlinehilfe" (als solche angepriesen) enthält
nix weiter als einen 1:1-Abzug der Website, aber das einzig Informative
dort ist die FAQ - die auch nicht wirklich hilft, wenn man nicht gerade
ein wirklich exotisches Problem hat.

Post by Peter Vratny
Scheiß OpenSource, nix in Hochglanz, alles muss man sich selbst suchen....

RMDDBR.

Post by Peter Vratny
http://www.imagemagick.org und google sind btw auch schon erfunden.

Wo auf der angegebenen Website <http://www.graphicsmagick.org> ein
"Handbuch" oder auch nur eine Befehslübersicht ist, wüßte ich allerdings
schon gerne. Und wenn ich eine Anleitung für GraphicsMagick suche, suche
ich nicht bei ImageMagick danach ("derived from"). Ich suche ja auch
nicht eine Anleitung für cdrecord auf der Website von cdda2wav.

Und google steuerte mich nach Dutzenden von Schrottseiten mit dem
weißnichtwievielten Treffer "zielstrebig" auf
<http://www-106.ibm.com/developerworks/library/l-graf/?ca=dnt-428>, was
dann auch nicht gerade zum Weiterlesen animiert. Geschweige denn, daß es
bei meinem speziellen Problem irgendwie nützlich wäre, was dort steht.

Das Parameterformat für composite hatte ich übrigens schon nach einer
Minute bei groups.google gefunden, und es *passiert* ja prinzipiell auch
was (nein, keine Fehlermeldung!), aber was an Doku *dabei* ist und/oder
*verlinkt* wird, ist eben einfach keine Doku.

Und da das Programm ja eh neu komprimiert, ist es sowieso nicht das was
ich suche. Zumal genau diese Tatsache auf der entsprechenden Seite
sowieso nicht vermerkt ist.

Danke trotzdem für Deinen "sarkasmusfreien" Hinweis.

Alan

[Peter Vratny]

Post by Alan Tiedemann
man Windows.

He! Es ist eine heilige Zeit! Du brauchst ja nicht gleich beleidigend
werden.

Ausserdem brauchst du das ja nicht mir zu sagen, _du_ hättest das tippen
müssen, dann hättest du dir die Arbeit des Suchens sparen können:

loki:~$ man Windows
No manual entry for Windows

Ebend!

Post by Alan Tiedemann
Bei der Windows-Version ist nix dabei. gm -help bringt eine klitzekleine

Na das ist doch was. Normalerweise sind da doch 400 Seiten clickable-Help
dabei mit sinnfreiem Inhalt (Ist das Problem gelöst? Nein, klicken Sie
hier.... Ist das Problem gelöst? Nein, klicken Sie hier... Ist das Pro....
Fragen Sie Ihren Administrator oder updaten Sie auf eine neue Version).

Post by Alan Tiedemann
C:\>gm -help
Version: GraphicsMagick 1.0.4 December 6, 2003 Q8

Ahh! Jetzt haben wir dich erwischt! Du hast die Nikolo Version!
Du musst auf die Christkindl-Version updaten, wenn du englisch kannst, auch
auf die Santa_Claus, die ist immer ein bisschen aktueller.

Ne sorry. Bin schon wieder ernst. Mit Windows kann ich dir leider nicht
helfen.

Post by Alan Tiedemann

Post by Peter Vratny
Scheiß OpenSource, nix in Hochglanz, alles muss man sich selbst suchen....

RMDDBR.

Hmmm. Jetzt hast du mich auch noch am linken Fuß erwischt. Muss ich den
Akronym-Finder anwerfen. Moment....

Ojemnie, heute ist nicht mein Tag. Guck mal Olli, was ich gefunden habe:

"RMDDBR? was´n das?
Ran mal drei der bär ruft? ... hi hi
im moment hat das wellental heimtückisch aus dem hinterhalt eine dicke große
realowelle über mich drüber geworfen...."

Das finde ich auch besser als

"Hihi Ihr wißt nicht RMDDBR ist ;-) ... Also im übertragenen Sinn ... Du
kannst mich mal!!!..."

Das ist irgendwie garstig - finde ich - und meinem sensiblen Gemüt nicht
zuzumuten.

Post by Alan Tiedemann

Post by Peter Vratny
http://www.imagemagick.org und google sind btw auch schon erfunden.

Wo auf der angegebenen Website <http://www.graphicsmagick.org> ein
"Handbuch" oder auch nur eine Befehslübersicht ist, wüßte ich allerdings
schon gerne. Und wenn ich eine Anleitung für GraphicsMagick suche, suche
ich nicht bei ImageMagick danach ("derived from"). Ich suche ja auch
nicht eine Anleitung für cdrecord auf der Website von cdda2wav.

Ähem, dann war wohl meine Kristallkugel kaputt, denn du antwortest auf

Post by Alan Tiedemann

Post by Peter Vratny
Da Du auch ImageMagick erwaehnt hattest: in der Doku zu

^^^^^^^^^^^ ^^

Post by Alan Tiedemann

Post by Peter Vratny
diesem Programm wird nicht behauptet, dass die Bilder ohne

^^^^^^^^^^^^^^^

Post by Alan Tiedemann

Post by Peter Vratny
eine Neukomprimierung zusammengesetzt werden.

Stimmt, in der Doku steht eigentlich sowieso *überhaupt nichts* zu dem

^^^^^^

Post by Alan Tiedemann
Programm. Zumindest habe ich keine Doku entdecken können, die dem Namen

^^^^^^^^

Post by Alan Tiedemann
gerecht wird :-(

Und wenn mich mein Sprachgefühl nicht im Stich läßt, bezieht sich das auf
ImageMagick.

Aber I-Tüpferl reiten bringt nichts. Schneit doch gerade so schön
draussen...

Post by Alan Tiedemann
Danke trotzdem für Deinen "sarkasmusfreien" Hinweis.

Gerne geschehen. Dieses Mal ist er, inkl. Draufgabe, gratis. Beim nächsten
Mal lass ich mir was anderes einfallen. Vielleicht kann ich dir sogar
helfen, wenn du nicht wieder mit Nikoloversionen daher kommst .-))

mfg
Peter

[Stefan Lagotzki]

Post by Peter Vratny
Gerne geschehen. Dieses Mal ist er, inkl. Draufgabe, gratis.

Der Witz ist ja, dass es genug Dokumentation gibt, man muss nur
kurz danach suchen. Sogar unter Windows (so selten ich damit arbeite)
findet sich doch eine Suchfunktion, in die man einen der Befehle
als Suchbegriff eingeben kann. Und auf der Webseite gibt es
ja -- man staune! -- ebenfalls eine Suchfunktion. Wenn man da
den Begriff 'montage' eingibt -- was ist wohl zu erwarten?

Stefan

.

[Peter Vratny]

Post by Stefan Lagotzki
ja -- man staune! -- ebenfalls eine Suchfunktion. Wenn man da
den Begriff 'montage' eingibt -- was ist wohl zu erwarten?

Na für diesen Wonnemonat natürlich 1., 8., 15., 22. und 29.

hth
Peter

[Stefan Lagotzki]

Hallo Alan,

aber sicher gibt es Doku zu ImageMagick, so z.B. Webseiten und
man-Pages sowie ein Diskussionsboard auf der Webseite. Die man-
Pages kann man auf modernen Linux-Systemen im Browser lesen. Man
kann sie sich auch in PDFs wandeln.

Stimmt, in der Doku steht eigentlich sowieso *ueberhaupt nichts* zu dem
Programm. Zumindest habe ich keine Doku entdecken koennen, die dem Namen
gerecht wird :-(

Besser suchen :-)

Stefan

.

[Alan Tiedemann]

Post by Stefan Lagotzki
aber sicher gibt es Doku zu ImageMagick,

Tja, GraphicsMagick ist "derived from" ImageMagick, allerdings wird bei
GraphicsMagick mit keinem Wort erwähnt, daß die Parameter exakt
dieselben sind. Da haben die GM-Macher offenbar geschlampt oder gepennt...

Post by Stefan Lagotzki
so z.B. Webseiten und
man-Pages sowie ein Diskussionsboard auf der Webseite.

Auf der GM-Website ist nichts dergleichen.

Post by Stefan Lagotzki
Die man-
Pages kann man auf modernen Linux-Systemen im Browser lesen.

man Windows.

Post by Stefan Lagotzki
Man kann sie sich auch in PDFs wandeln.

Was will ich mit PDFs, die sind ja noch unhandlicher als eine Textdatei ;-)

Post by Stefan Lagotzki

Stimmt, in der Doku steht eigentlich sowieso *ueberhaupt nichts* zu dem
Programm. Zumindest habe ich keine Doku entdecken koennen, die dem Namen
gerecht wird :-(

Besser suchen :-)

Oder die GM-Macher überarbeiten ihre Seite mal so, daß man auch als
relativ unbedarfter Leser irgendwas *Sinnvolles* findet. Und wenn es nur
ein Hinweis wäre, daß man für eine Anleitung gefälligst bei IM suchen soll.

Alan

[Stefan Lagotzki]

Hallo Alan,

im Programmordner von GraphicsMagick liegt eine Datei
"index.html", die sollte Dir weiterhelfen! Von dort kannst
Du alle einzelnen Seiten im darunter liegenden Ordner "www"
aufrufen (oder Du rufst da direkt die Seite zu dem Werkzeug
auf, das Dich interessiert). Normalerweise findet man auch
im Startmenue eine Verknuepfung zu der HTML-Hilfe.

Stefan

.

[Alan Tiedemann]

Post by Stefan Lagotzki
im Programmordner von GraphicsMagick liegt eine Datei
"index.html", die sollte Dir weiterhelfen!

Das ist eine 1:1-Kopie der Website.

Post by Stefan Lagotzki
Von dort kannst
Du alle einzelnen Seiten im darunter liegenden Ordner "www"
aufrufen (oder Du rufst da direkt die Seite zu dem Werkzeug
auf, das Dich interessiert).

Es ist keine Seite zu Werkzeugen dabei.

Oder welches der folgenden Kapitel würde dich diesbezüglich "anspringen"?

[Home] [Mission Statement] [Development Process] [Contribute] [Download]
[Installation] [CVS] [Mailing Lists] [FAQ] [Formats] [News ] [ChangeLog]
[Report Bugs] [Utilities] [Programming] [Books] [Links]

Post by Stefan Lagotzki
Normalerweise findet man auch
im Startmenue eine Verknuepfung zu der HTML-Hilfe.

So ist es. Nur ist das eben keine Hilfe, sondern eine 1:1-Kopie der Website.

Achja, in der lokalen Version der Website fehlt natürlich der alles
entscheidende Link zu ImageMagick - damit ist jemand ohne
Internet-Zugang dann gänzlich aufgeschmissen.

Kurz: Die "Anleitung" zu GraphicsMagick ist nichtexistent.

Alan

[Stefan Lagotzki]

Post by Alan Tiedemann
Das ist eine 1:1-Kopie der Website.

Und was ist daran denn bitte falsch? Auch auf der GM-Website
liegen doch die Seiten zu allen Werkzeugen, wie zum Beispiel:

http://www.graphicsmagick.org/www/montage.html
http://www.graphicsmagick.org/www/composite.html
http://www.graphicsmagick.org/www/convert.html


Am wichtigsten ist die Seite mit den Optionen, die alle
Utilities betreffen. Die sollte man immer in Griffweite
haben:

http://www.graphicsmagick.org/www/GraphicsMagick.html

Post by Alan Tiedemann
Es ist keine Seite zu Werkzeugen dabei.

Ach ja. Aber zu [Utilities].

Post by Alan Tiedemann
Oder welches der folgenden Kapitel würde dich diesbezüglich "anspringen"?

[Index-Webseite --> auf das Link Utilities]
file:///C:/Programme/GraphicsMagick-1.0.4-Q16/index.html

[Utilities]
file:///C:/Programme/GraphicsMagick-1.0.4-Q16/www/utilities.html

[Dort sind Links zu *allen* Werkzeugen, zum Beispiel "gm montage"]
file:///C:/Programme/GraphicsMagick-1.0.4-Q16/www/montage.html

[Und zur Einrichtung unter Windows findet sich noch:]
file:///C:/Programme/GraphicsMagick-1.0.4-Q16/www/windows.html

Der Pfad wird bei Dir wahrscheinlich etwas anders heissen,
weil Du IIRC eine Q8-Version hast. Aber auch in meinem Q8
(Version 1.02) ist das genauso.

Post by Alan Tiedemann
So ist es. Nur ist das eben keine Hilfe, sondern eine 1:1-Kopie der Website.

Siehe oben. Auf der Website sind die selben umfangreichen
Hilfe-Seiten vorhanden, wie auf dem PC nach der Installation.
Also ist es auch gerechtfertigt, die Website zu kopieren.

Post by Alan Tiedemann
Achja, in der lokalen Version der Website fehlt natürlich der alles
entscheidende Link zu ImageMagick - damit ist jemand ohne
Internet-Zugang dann gaenzlich aufgeschmissen.

Nein. Wenn man richtig hinschaut, ist man keineswegs aufgeschmissen :-)


Stefan

.

[Alan Tiedemann]

Post by Stefan Lagotzki

Post by Alan Tiedemann
Das ist eine 1:1-Kopie der Website.

Und was ist daran denn bitte falsch? Auch auf der GM-Website
http://www.graphicsmagick.org/www/montage.html
http://www.graphicsmagick.org/www/composite.html
http://www.graphicsmagick.org/www/convert.html

Man muß erstmal darauf kommen, das unter [Utilities] zu suchen. Darunter
stelle ich mir *Zusatz*programme vor, aber nicht etwas wie [Commands],
[Parameters], [Options], [Tools], oder, noch besser, [Manual].

Kurz: Ich hab's jetzt auch gefunden. Die Wortwahl auf der Website ist
*extrem* unglücklich.

Post by Stefan Lagotzki

Post by Alan Tiedemann
Es ist keine Seite zu Werkzeugen dabei.

Ach ja. Aber zu [Utilities].

Bei PC-Software versteht man unter [Utilities] Zusatzprogramme. Nicht
aber Programm-Optionen. Wie gesagt - extrem unglückliche Wortwahl, dazu
Überfrachtung mit vielen Begriffen, die wirklich *nur* für Leute
interessant sind, die zur Entwicklung der Software beitragen wollen.

Post by Stefan Lagotzki

Post by Alan Tiedemann
Achja, in der lokalen Version der Website fehlt natürlich der alles
entscheidende Link zu ImageMagick - damit ist jemand ohne
Internet-Zugang dann gaenzlich aufgeschmissen.

Nein. Wenn man richtig hinschaut, ist man keineswegs aufgeschmissen :-)

Und wo, bitte, steht der?

Wie gesagt - eine etwas geschicktere Begriffswahl hätte derartige
Mißverständnisse, wie sie dieser Thread zutage fördert, verhindert.

Und nein, ich bin *kein* DAU, ich benutze Computer seit ca. 1984, fühle
mich auf der Konsole auch eher zu Hause als mit der Maus, aber so eine
unübersichtliche Menü-Struktur habe ich bisher selten erlebt. Dabei
vermittelt das Design der Website doch Professionalität... Naja, okay,
das ist hier OffTopic.

Danke für den Hinweis.

PS: Auch da steht leider nix dazu, ob GM/IM bei JPGs neu komprimiert.

Alan

[Alan Tiedemann]

Post by Alan Tiedemann
Leider scheitert Jpegjoin (Version 2002.01) bei mir ab einer bestimmten
Größe. Ich habe 6x8 Kacheln, je 3.952 x 3.616 Pixel. Gesamtgröße also
23.712 x 28.928 Pixel. Das ist so in etwa das "Standardformat" der
Karten ;-)

Ich habe inzwischen vom Autor von JpegJoin eine ausführliche Mail
bekommen (vielen Dank, Guido!). Das Problem liegt wohl bei der
zugrundeliegenden "jpegtran -drop"-Routine, er wird sich das bei
Gelegenheit mal ansehen. Es ist offenbar so, daß die Routinen sehr
speicherintensiv sind. Versprechen kann er aber nichts - kann ich
verstehen, wenn da irgendwas tief drin geändert werden müßte, zieht das
richtig Arbeit nach sich, ich kenne sowas ;-)

Da eine Rücksprache mit der Druckerei ergeben hat, daß mehr als 100-150
DPI sowieso nicht nötig sind (und für A0 somit ca. 7000x5000 Pixel
reichen), ist das auch erstmal nicht so dringend.

Alan

[Guido Vollbeding]

Post by Alan Tiedemann

Post by Alan Tiedemann
Leider scheitert Jpegjoin (Version 2002.01) bei mir ab einer bestimmten
Größe. Ich habe 6x8 Kacheln, je 3.952 x 3.616 Pixel. Gesamtgröße also
23.712 x 28.928 Pixel. Das ist so in etwa das "Standardformat" der
Karten ;-)

Ich habe inzwischen vom Autor von JpegJoin eine ausführliche Mail
bekommen (vielen Dank, Guido!). Das Problem liegt wohl bei der
zugrundeliegenden "jpegtran -drop"-Routine, er wird sich das bei
Gelegenheit mal ansehen. Es ist offenbar so, daß die Routinen sehr
speicherintensiv sind. Versprechen kann er aber nichts - kann ich
verstehen, wenn da irgendwas tief drin geändert werden müßte, zieht das
richtig Arbeit nach sich, ich kenne sowas ;-)

Im Prinzip ist Jpegjoin das richtige Tool dafür, mir ist nichts anderes
bekannt was *verlustfrei* JPEGs zusammensetzen könnte (ImageMagick
arbeitet auf Pixelbasis und muss neukomprimieren).

Dass Jpegjoin *verlustfrei* arbeitet bedeutet aber nicht, dass es
unbedingt weniger Speicher benötigt. Es dürfte im Gegenteil sogar
mehr sein, weil die kompletten DCT-Koeffizienten des gesamten Bildes
in den Speicher geladen werden und dort 16 Bit statt 8 Bit pro Pixel
und Komponente belegen (effektiv 12 Bit). Im Falle einer
Farbunterabtastung könnte sich das teilweise reduzieren,
aber es bleibt recht viel.

Hier stößt man tatsächlich an Speicher- und Bearbeitungsgrenzen.

Viele Grüße
Guido

[Alan Tiedemann]

Post by Guido Vollbeding

Post by Alan Tiedemann
Ich habe inzwischen vom Autor von JpegJoin eine ausführliche Mail
bekommen (vielen Dank, Guido!). Das Problem liegt wohl bei der
zugrundeliegenden "jpegtran -drop"-Routine, er wird sich das bei
Gelegenheit mal ansehen. Es ist offenbar so, daß die Routinen sehr
speicherintensiv sind. Versprechen kann er aber nichts - kann ich
verstehen, wenn da irgendwas tief drin geändert werden müßte, zieht das
richtig Arbeit nach sich, ich kenne sowas ;-)

[...]
Dass Jpegjoin *verlustfrei* arbeitet bedeutet aber nicht, dass es
unbedingt weniger Speicher benötigt. Es dürfte im Gegenteil sogar
mehr sein, weil die kompletten DCT-Koeffizienten des gesamten Bildes
in den Speicher geladen werden und dort 16 Bit statt 8 Bit pro Pixel
und Komponente belegen (effektiv 12 Bit). Im Falle einer
Farbunterabtastung könnte sich das teilweise reduzieren,
aber es bleibt recht viel.

Hm, okay, ich habe mich mit den Interna von JPGs bisher nicht wirklich
beschäftigt. Ich hatte mir gedacht (jaja, denken ist Glückssache!), daß
man einfach die "Teile" ins RAM lädt (also ein 4-MiB-JPG belegt 4 MiB
RAM) und dann "in der richtigen Reihenfolge" mit neuen Headern auf die
Platte schreibt. Aber dem scheint ja nicht so zu sein ;-)

Post by Guido Vollbeding
Hier stößt man tatsächlich an Speicher- und Bearbeitungsgrenzen.

Hmja, okay. Ich habe jetzt sowieso eine wahrscheinlich elegantere
Methode gefunden, an diese Bilder zu kommen. Das sind dann zwar erstmal
TIFFs (bis zu 3 GiB groß), aber die kann mein PC komischerweise
bearbeiten, wenn auch ("dank" Swapfile) sehr langsam.

Danke für alle Deine Hinweise, auch per Mail!

Gruß,
Alan