Große Bilder und imagemagick
Hallo, ich habe einige Riesenbilder: eingescannt mit 1200 dpi und etwa 8000x10000 Pixel. Da ist eine tiff-Datei entstanden, die 175 MB auf die Waage bringt. Diese will ich rotieren und für normalen Bedarf verkleinern. Mit mogrify -rotate -90 fluechtlingslager-0010.tiff ; mogrify -format JPG -scale 4096 fluechtlingslager-0010.tiff auf der commandline habe ich den Wahnsinn unternommen. Der erste Befehl zum rotieren dauert nun schon 4 Stunden und nimmt den Rechner ( AMD 3200+, 1 GB RAM) vollständig in Anspruch. Das verkleinern hatte ich schon öfter mal gemacht und das dauert 15 bis 30 Minuten. Natürlich hätte ich die Befehle andersherum ausführen können (wenn ich gewußt hätte, daß rotate so langsam ist), aber ich wollte die Breite von 4096 nicht umständlich umrechnen, damit es beim Bild richtig passt. Egal: habt ihr noch andere Bildverarbeitungswerkzeuge? gimp ist in dieser Hinsicht ja noch viel langsamer (aber ansonsten klasse). Wie hätte ich das besser machen können? Vielen Dank für Antworten ... Manfred
Ich ergänze nochmal: ein Bekannter kam mit seinem Mini-PC vorbei, etwa gleiche Ausstattung (AMD 3000, 1 GB RAM), aber Windows XP Prof. installiert. Er startete Adobe Photoshop und lud das Riesenbild. Innerhalb von 30 Sekunden wurde das Bild gedreht und nochmal 30 Sekunden war es auf 300 dpi reduziert und als Jpeg gespeichert. Nun, da behaupte ich doch mal, daß die Programmierer von ImageMagick ziemlichen Bockmist hinsichtlich der Performance gebaut haben. Hoffentlich habe ich mal Zeit, mir den Source davon anzusehen... Grüße Manfred
Hallo Manfred, On Thu, Jan 06, 2005 at 02:10:14PM +0100, Manfred Rebentisch wrote:
Ich ergänze nochmal: ein Bekannter kam mit seinem Mini-PC vorbei, etwa gleiche Ausstattung (AMD 3000, 1 GB RAM), aber Windows XP Prof. installiert. Er startete Adobe Photoshop
in 30 min *fg* SCNR
und lud das Riesenbild. Innerhalb von 30 Sekunden wurde das Bild gedreht und nochmal 30 Sekunden war es auf 300 dpi reduziert und als Jpeg gespeichert.
[ ] Du hast DMA aktiviert? [ ] Du hast dir vmstat/top angeschaut?
Nun, da behaupte ich doch mal, daß die Programmierer von ImageMagick ziemlichen Bockmist hinsichtlich der Performance gebaut haben. Hoffentlich habe ich mal Zeit, mir den Source davon anzusehen...
mach das. Und zeig uns doch mal deine Kommandozeilen. Greetings Daniel -- In diesem Staat werden Verschlüsselungsreglementierungen geplant. Zu Risiken und Nebenwirkungen lesen Sie bitte 1984 und fragen Sie Ihren Historiker oder Ihre Großeltern. (Christopher Creutzig)
Am Donnerstag, 6. Januar 2005 15:04 schrieb Daniel Lord:
[ ] Du hast DMA aktiviert?
Ja
[ ] Du hast dir vmstat/top angeschaut? Ja, top. Ich hatte ein Average Load von 5 bis 7 (vor dem Komma!), eine vollständige Auslastung des RAMs und die Swap-Partition war kaum benutzt. Die anderen Angaben habe ich mir nicht gemerkt.
Nun, da behaupte ich doch mal, daß die Programmierer von ImageMagick ziemlichen Bockmist hinsichtlich der Performance gebaut haben. Hoffentlich habe ich mal Zeit, mir den Source davon anzusehen...
mach das. Und zeig uns doch mal deine Kommandozeilen.
Auch das: mogrify -rotate -90 fluechtlingslager-0010.tiff mogrify -format JPG -scale 4096 fluechtlingslager-0010.tiff Im übrigen handelte es sich um 14000x9000 Pixel. Ich habe den Prozeß nach 5 Stunden abgebrochen. Da war mogrify noch beim rotieren...
Greetings Daniel -- In diesem Staat werden Verschlüsselungsreglementierungen geplant. Zu Risiken und Nebenwirkungen lesen Sie bitte 1984 und fragen Sie Ihren Historiker oder Ihre Großeltern. (Christopher Creutzig)
Ok, nicht schlecht die Signatur... Manfred
Manfred Rebentisch schrieb:
Ich ergänze nochmal: ein Bekannter kam mit seinem Mini-PC vorbei, etwa gleiche Ausstattung (AMD 3000, 1 GB RAM), aber Windows XP Prof. installiert. Er startete Adobe Photoshop und lud das Riesenbild. Innerhalb von 30 Sekunden wurde das Bild gedreht und nochmal 30 Sekunden war es auf 300 dpi reduziert und als Jpeg gespeichert.
Nun, da behaupte ich doch mal, daß die Programmierer von ImageMagick ziemlichen Bockmist hinsichtlich der Performance gebaut haben. Hoffentlich habe ich mal Zeit, mir den Source davon anzusehen...
Da kann ich jetzt ja nicht wiederstehen: Wir arbeiten hier an einer Lösung zur Verarbeitung großformatiger Images und da habe ich mal ein entsprechendes Testbild erzeugt (8000x1000 Pixel, 24Bit RGB). Handgestoppt kommen wir auf 15 Sekunden (Hardware: AMD 3200+, 1 GB RAM, Win XP Pro)... Zum Vergleich: Photoshop 7 brauchte zum Drehen 33 Sekunden (aber 55 Sekunden bis PS wieder arbeitsbereit war). Sorry, aber ich konnte wie gesagt nicht wiederstehen. Ciao Michael -- Michael Wagner RATIO Entwicklungen GmbH Phone :+49-(0)40-369007-77 Admiralitaetstr. 59 Fax: +49-(0)40-369007-75 20459 Hamburg Email: mailto:mwa@ratio.de
Am Freitag, 7. Januar 2005 13:13 schrieb Michael Wagner:
Manfred Rebentisch schrieb:
Ich ergänze nochmal: ein Bekannter kam mit seinem Mini-PC vorbei, etwa gleiche Ausstattung (AMD 3000, 1 GB RAM), aber Windows XP Prof. installiert. Er startete Adobe Photoshop und lud das Riesenbild. Innerhalb von 30 Sekunden wurde das Bild gedreht und nochmal 30 Sekunden war es auf 300 dpi reduziert und als Jpeg gespeichert.
Da kann ich jetzt ja nicht wiederstehen: Wir arbeiten hier an einer Lösung zur Verarbeitung großformatiger Images und da habe ich mal ein entsprechendes Testbild erzeugt (8000x1000 Pixel, 24Bit RGB).
Handgestoppt kommen wir auf 15 Sekunden (Hardware: AMD 3200+, 1 GB RAM, Win XP Pro)... Zum Vergleich: Photoshop 7 brauchte zum Drehen 33 Sekunden (aber 55 Sekunden bis PS wieder arbeitsbereit war).
Sorry, aber ich konnte wie gesagt nicht wiederstehen.
Na denn.... Ich hoffe, du meintest 8000*10000 und nicht 8000*1000? Da ich "nur" 512 MB habe, nehme ich eine 24-Bit Grafik mit 5000*7000. Der simpelste Versuch: Mit Kuickshow öffnen: 19 Sekunden In Kuickschow drehen: 8 Sekunden Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/
Michael Hoehne schrieb:
Am Freitag, 7. Januar 2005 13:13 schrieb Michael Wagner:
Manfred Rebentisch schrieb:
[snip]
Na denn.... Ich hoffe, du meintest 8000*10000 und nicht 8000*1000? Sorry, war ein Tippfehler. Natürlich meine ich 8000*10000...
Da ich "nur" 512 MB habe, nehme ich eine 24-Bit Grafik mit 5000*7000. Der simpelste Versuch:
Mit Kuickshow öffnen: 19 Sekunden In Kuickschow drehen: 8 Sekunden
Ciao Michael
Am Donnerstag, den 06.01.2005, 14:10 +0100 schrieb Manfred Rebentisch:
Nun, da behaupte ich doch mal, daß die Programmierer von ImageMagick ziemlichen Bockmist hinsichtlich der Performance gebaut haben. Hoffentlich habe ich mal Zeit, mir den Source davon anzusehen...
ImageMagick ist *leider* und gegen meinen lauthals geäusserten Protest auf allen mir bekannten Distris mit 16-Bit Farbtiefe kompiliert. Wenn du irgendwas mit ImageMagick machst, werden die Daten also auf 16-Bit hochgewuchtet, die Operation wird durchgeführt und die Daten werden wieder auf die normale Farbtiefe runtergerechnet. Lösung: Rekompilieren mit 8 Bit, und unbedingt bei ImageMagick.org und bei $DISTRIBUTOR beschweren. Kein Mensch braucht 16 Bit. Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Sonntag, 9. Januar 2005 00:06 schrieb Joerg Rossdeutscher:
Am Donnerstag, den 06.01.2005, 14:10 +0100 schrieb Manfred Rebentisch: [...] ImageMagick ist *leider* und gegen meinen lauthals geäusserten Protest auf allen mir bekannten Distris mit 16-Bit Farbtiefe kompiliert. Wenn du irgendwas mit ImageMagick machst, werden die Daten also auf 16-Bit hochgewuchtet, die Operation wird durchgeführt und die Daten werden wieder auf die normale Farbtiefe runtergerechnet.
Lösung: Rekompilieren mit 8 Bit, und unbedingt bei ImageMagick.org und bei $DISTRIBUTOR beschweren. Kein Mensch braucht 16 Bit.
Sicher? auch nicht im Prepress? Oder warum nehmen da die meisten immer noch Photoshop und QuarkExpress? *SCNR* Ratti, ich wäre da nicht so sicher, im Tonbereich haben bis vor zwei Jahren auch alle behauptet, kein Mensch bräuchte mehr als 16 Bit (-was für mp3 User ja auch zutrifft *gg*), mittlerweile basteln alle ernstzunehmenden Produzenten und Gerätehersteller an 32 Bit Lösungen. Gruß Peter -- If I had a message, I´d write a letter! (R. Polanski)
Moin, Am Sonntag, den 09.01.2005, 11:29 +0100 schrieb Peter Baumgartner:
Am Sonntag, 9. Januar 2005 00:06 schrieb Joerg Rossdeutscher:
Lösung: Rekompilieren mit 8 Bit, und unbedingt bei ImageMagick.org und bei $DISTRIBUTOR beschweren. Kein Mensch braucht 16 Bit.
Sicher? auch nicht im Prepress? Oder warum nehmen da die meisten immer noch Photoshop und QuarkExpress?
*SCNR*
Ratti, ich wäre da nicht so sicher, im Tonbereich haben bis vor zwei Jahren auch alle behauptet, kein Mensch bräuchte mehr als 16 Bit (-was für mp3 User ja auch zutrifft *gg*), mittlerweile basteln alle ernstzunehmenden Produzenten und Gerätehersteller an 32 Bit Lösungen.
Bist du sicher, daß du jetzt nicht irgendwas durcheinander bringst? Dein Hinweis auf Photoshop und Quark lässt mich das vermuten... Ein 16-Bit-Image ist ein Bild, bei dem jeder Pixel pro Farbkanal eine Abstufung von 0-65535 haben kann. Das hat jetzt nichts zu tun mit RGB oder CMYK oder so. Du hast auch keinen "breiteren" Farbraum, du hast nur feinere Abstufungen. Sonst nichts. Photoshop und Quark (und InDesign und Freehand und Illustrator und...) können sowohl mit 8 als auch mit 16 Bit umgehen. Ich versichere dir aber, in den letzten 10 Jahren DTP noch niemals ein 16-Bit-Bild in die Finger bekommen zu haben. Es arbeitet einfach niemand damit. Und wenn du bei Photoshop ein neues Bild erstellst, dann ist das *selbstverständlich* 8 Bit. Es gibt dafür sicherlich Ausnahmen. Wer ein komplettes Baugerüst mit einem Farbverlauf abdecken will, wird für sein Motiv vermutlich 16 Bit wählen, weil man für 20 Meter Breite lieber 60000 Farben nehmen will statt 200, sonst gibt es Stufen (noch besser wäre allerdings das absichtliche hinzufügen von Störungen, aber egal jetzt...). Aber alles unter 1 Meter Breite im Ausdruck arbeitet mit 8 Bit. Ich glaube, das mit den 16 Bit bei IM ist eine Marketingentscheidung gewesen - und dazu eine, die nach hinten losgeht ("...so langsaaaam...") Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Sonntag, 9. Januar 2005 13:50 schrieb Joerg Rossdeutscher:
Moin,
Am Sonntag, den 09.01.2005, 11:29 +0100 schrieb Peter Baumgartner:
Am Sonntag, 9. Januar 2005 00:06 schrieb Joerg Rossdeutscher:
Lösung: Rekompilieren mit 8 Bit, und unbedingt bei ImageMagick.org und bei $DISTRIBUTOR beschweren. Kein Mensch braucht 16 Bit.
Sicher? auch nicht im Prepress? Oder warum nehmen da die meisten immer noch Photoshop und QuarkExpress?
Bist du sicher, daß du jetzt nicht irgendwas durcheinander bringst? Dein Hinweis auf Photoshop und Quark lässt mich das vermuten...
Ein 16-Bit-Image ist ein Bild, bei dem jeder Pixel pro Farbkanal eine Abstufung von 0-65535 haben kann. Das hat jetzt nichts zu tun mit RGB oder CMYK oder so. Du hast auch keinen "breiteren" Farbraum, du hast nur feinere Abstufungen. Sonst nichts.
Er hat wahrscheinlich (wie ich zuerst auch) gedacht, du meinst 8-Bit im "üblichen" Sinne der Malprogramme: 256 Farben Palettenbild. Du meintest aber 8-Bit-Kanäle, was ja in etwa der "üblichen" 24-Bit entspricht. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/
Am Sonntag, 9. Januar 2005 14:12 schrieb Michael Hoehne:
Am Sonntag, 9. Januar 2005 13:50 schrieb Joerg Rossdeutscher:
Moin, [....]
Er hat wahrscheinlich (wie ich zuerst auch) gedacht, du meinst 8-Bit im "üblichen" Sinne der Malprogramme: 256 Farben Palettenbild. Du meintest aber 8-Bit-Kanäle, was ja in etwa der "üblichen" 24-Bit entspricht.
OK, OK, OK, ich nehme alles zurück und behaupte das Gegenteil ;-) 24-bit ist natürlich OK, solange die Bilder nicht zu groß sind, sonst werden die Verläufe etwas "grisselig" . Denk mal an einen >5000 dpi Scan mit einem Scanner, der nicht rauscht, aber das kennst Du ja wahrscheinlich. Außerdem dürfte das wirklich selten sein (bei einem Belichter habe ich mal ein Tiff mit 850 MB liegen sehen, das hat dessen 9500´er Mac mit 512 MB ganz schön ins schwitzen gebracht). Gruß und nichts für ungut Peter -- If I had a message, I´d write a letter! (R. Polanski)
Moin, Am Sonntag, den 09.01.2005, 14:12 +0100 schrieb Michael Hoehne:
Er hat wahrscheinlich (wie ich zuerst auch) gedacht, du meinst 8-Bit im "üblichen" Sinne der Malprogramme: 256 Farben Palettenbild. Du meintest aber 8-Bit-Kanäle, was ja in etwa der "üblichen" 24-Bit entspricht.
Ach so. Verstehe. Ne, das ist ja eine Technik von vorm 2. Weltkrieg. :-) Deine Diktion ist bei uns deswegen nicht üblich, weil sie von einer festen Kanal-Anzahl von 3 ausgeht. Können wir aber nicht. "24-Bit" könnte ja z.B. ein einfarbiges Bild mit 24 Bits pro Pixel bedeuten. Oder RGB mit 8 Bit pro Farbe. Oder ein 6-Kanal-Sonderfarbbild mit 4 Bit pro Farbe. Oder... :-) Deswegen benennen wir lieber die Bits pro Kanal. Da sind dann 8 Bit 0-255 pro Kanal, egal ob RGB oder CMYK oder... Bei einen Wechsel des Farbraums bleibt der Wert trotzdem konstant. Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Sonntag, 9. Januar 2005 15:25 schrieb Joerg Rossdeutscher:
Moin,
Am Sonntag, den 09.01.2005, 14:12 +0100 schrieb Michael Hoehne:
Er hat wahrscheinlich (wie ich zuerst auch) gedacht, du meinst 8-Bit im "üblichen" Sinne der Malprogramme: 256 Farben Palettenbild. Du meintest aber 8-Bit-Kanäle, was ja in etwa der "üblichen" 24-Bit entspricht.
Ach so. Verstehe. Ne, das ist ja eine Technik von vorm 2. Weltkrieg. :-)
Deine Diktion ist bei uns deswegen nicht üblich, weil sie von einer festen Kanal-Anzahl von 3 ausgeht. Können wir aber nicht.
"24-Bit" könnte...
Beim zweiten Lesen habe ich mir das dann auch gedacht ;-) Ich bin zwar kein ausgesprochener Experte in solchen Sachen, aber ich mußte mich in den letzten Monaten häufiger als Layouter betätigen, dabei kommt man um solche Infos nicht herum. Alleine das Umrechnen der Farbräume, "normale" und "Schmuck"farben, Oberflächenstruktur,.... Was ist das Leben am Bilschirm doch einfach ;-))) Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/
Am Donnerstag, 6. Januar 2005 12:35 schrieb Manfred Rebentisch:
Hallo, ich habe einige Riesenbilder: eingescannt mit 1200 dpi und etwa 8000x10000 Pixel. Da ist eine tiff-Datei entstanden, die 175 MB auf die Waage bringt.
Diese will ich rotieren und für normalen Bedarf verkleinern. Mit
mogrify -rotate -90 fluechtlingslager-0010.tiff ; mogrify -format JPG -scale 4096 fluechtlingslager-0010.tiff
Ich habe auch schon seit längerem von ImageMagick Abschied genommen, wenn es um große Datenmengen geht (u. a. hat mir convert mal reproduzierbar sämtlichen RAM + SWAP innerhalb von Sekunden zugenagelt, als ich ca. 50 s/w-TIFFs in Multipage-TIFF verwandeln wollte - das waren 2 x 1 GB). Schau Dir mal das netpbm-Paket an (ist bei SuSE dabei), das sind lauter klitzekleine Spezialprogramme. Was Du suchst, sollte ungefähr so gehen (man-Pages lesen): tifftopnm fluechtlingslager-0010.tiff | pnmrotate ... | pnmscale ... | pnmtojpeg >fluechtlingslager-0010.jpg Jan -- Linux-Quickies: http://www.jan-trippler.de PingoS: http://www.pingos.org
Am Donnerstag, 6. Januar 2005 19:39 schrieb Jan Trippler:
Schau Dir mal das netpbm-Paket an (ist bei SuSE dabei), das sind lauter klitzekleine Spezialprogramme. Was Du suchst, sollte ungefähr so gehen (man-Pages lesen):
tifftopnm fluechtlingslager-0010.tiff | pnmrotate ... | pnmscale ... | pnmtojpeg >fluechtlingslager-0010.jpg
Jan
Hey, super! Das schaue ich mal an. Danke für den Tip! Manfred
Am Donnerstag, 6. Januar 2005 19:39 schrieb Jan Trippler:
Am Donnerstag, 6. Januar 2005 12:35 schrieb Manfred Rebentisch:
ich habe einige Riesenbilder: eingescannt mit 1200 dpi und etwa 8000x10000 Pixel. Da ist eine tiff-Datei entstanden, die 175 MB auf die Waage bringt.
Diese will ich rotieren und für normalen Bedarf verkleinern. Mit
Schau Dir mal das netpbm-Paket an (ist bei SuSE dabei), das sind lauter klitzekleine Spezialprogramme. Was Du suchst, sollte ungefähr so gehen (man-Pages lesen):
Das Paket ist wirklich klasse! Ich habe damit mal einige Wochen gearbeitet da es das für die verschiedensten Betriebsysteme gibt. Zum Rotieren: Ich hatte damals ein Script gefunden (finde es aber leider nicht wieder), daß die Aufgabe mit den netpbm-Utilities folgendermaßen gelöst hat: a) Das große Bild wird in mehrere Streifen (horizontal) zerschnitten. b) Die Streifen werden ebenfalls in handliche Teile zersägt. c) Jedes der Einzelbilder (mit "vertretbarer" Größe) wird einzeln gedreht! d) Das Bild wird wieder zusammen gesetzt. Damit konnte man auch verhältinismäßig "gigantische" Bilder auf einem 7MHz/8MB Amiga bzw Atari rotieren. Im Original ging nur eine 90 Grad Rechtsdrehung, aber ein horizontales/vertikales Kippen mit einem der Tools ist ja lange nicht so aufwändig, wie das Drehen. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/
Am Donnerstag, 6. Januar 2005 22:19 schrieb Michael Hoehne:
Am Donnerstag, 6. Januar 2005 19:39 schrieb Jan Trippler:
Am Donnerstag, 6. Januar 2005 12:35 schrieb Manfred Rebentisch:
ich habe einige Riesenbilder: eingescannt mit 1200 dpi und etwa 8000x10000 Pixel. Da ist eine tiff-Datei entstanden, die 175 MB auf die Waage bringt.
Diese will ich rotieren und für normalen Bedarf verkleinern. Mit
Schau Dir mal das netpbm-Paket an (ist bei SuSE dabei), das sind lauter klitzekleine Spezialprogramme. Was Du suchst, sollte ungefähr so gehen (man-Pages lesen):
Das Paket ist wirklich klasse! Ich habe damit mal einige Wochen gearbeitet da es das für die verschiedensten Betriebsysteme gibt.
Zum Rotieren: Ich hatte damals ein Script gefunden (finde es aber leider nicht wieder), daß die Aufgabe mit den netpbm-Utilities folgendermaßen gelöst hat: [...]
Das netpbm-Paket entwickelt sich nach meiner Beobachtung sehr stürmisch - mittlerweile ist auch ein pnmrotate da (gab es IIRC bei meinem ersten Besuch noch nicht), genauso wie die Konverter von / nach JPEG. Das Schöne ist, dass die Programme so klein und handlich (und schnell) sind. Ich habe mich in Bezug auf TIFF-Bearbeitung inzwischen fast komplett von ImageMagick verabschiedet - es mag ja als "Schweizer Taschenmesser der Bildbearbeitung" gelten, aber es macht seine Sache IMHO oft nicht mehr gut - zu fett, zu gewaltig, zu viele Fehler, zu viele Abstürze, zu weit entfernt von "KISS". Für Leute mit Programmierkenntnissen ist übrigens auch tifflib zu empfehlen (auf sourceforge.net). Jan -- Linux-Quickies: http://www.jan-trippler.de PingoS: http://www.pingos.org
participants (7)
-
Daniel Lord -
Jan.Trippler＠t-online.de -
Joerg Rossdeutscher -
Manfred Rebentisch -
Michael Hoehne -
Michael Wagner -
Peter Baumgartner