Programm um übergrosse Bilder anzuzeigen?

[Omnicron]

Hallo, suche ein Programm mit dem sich übergrosse Bilder anzeigen lassen.
(jpg >200MB) Irfanview sagt es kann nicht genügend Speicher zuweisen und GIMP bleibt auch hängen.

[Pinoccio]

Ein jpg ist ja komprimiert, wenn das so schon 200 MB groß ist, wird es original wohl noch mal ziemlich viel größer sein. (Bilder verschiedener Digicams, die hier auf meiner Platte liegen, sind meist 1:10 bis 1:15 komprimiert).
Dann wird wohl der Speicher nicht ausreichen, da Windows ja maximal 2 (3?) GB pro Prozess zulässt, selbst mit Swap-File.
Evtl mal 64-bit-Linuxer fragen. Oder selbst was schreiben ... ;-)

BTW: 200MB (unkomprimiert) das wären über 8000*8000 Pixel, wo bekommt man so ein Bild her bzw wozu?

mfg Sebastian

[Omnicron]

Satellitenbild 21600x21600 :ugly:

[Muh-sagt-die-Kuh]

Theoretisch sollten die Programme sowas anzeigen können.....wenn sie intelligent mit dem Speicher umgehen und auch nicht davor zurückschrecken, bereits dekodierte Bildteile wieder zu löschen...im Speicher muss nur das sein, was auf dem Bildschirm angezeigt wird...

/edit: ACDSee ist auch nicht intelligent, das packt in jeder Zoomstufe das Bild komplett aus......beim 100% Level erzeugt ein 9600x9600 JPEG (14 MB Original) einen Speichverbrauch von ~270 MiB.

[HellHorse]

Theoretisch sollten die Programme sowas anzeigen können.....wenn sie intelligent mit dem Speicher umgehen und auch nicht davor zurückschrecken, bereits dekodierte Bildteile wieder zu löschen...im Speicher muss nur das sein, was auf dem Bildschirm angezeigt wird...

Ich denke nicht, dass ein allgemeines Bildbetrachtungsprogramm darauf ausgelegt ist, denn:

Normalerweise wird ein Bild beim öffnen so verkleinert, dass es auf den Bildschirm passt. Es muss also sowieso das ganze geladen und dekodiert werden.
Jedes mal, wenn verschoben oder gezomt wird, muss zumindest neu dekodiert werden. Falls nicht ein Puffer vom File gehalten wird (würde der Forderung nach möglichst wenig Speicherverbrach widersprechen), muss sogar das File neu gelesen werden. Das erhöht extrem die Reaktionszeit des Programmes und das sehen User nicht gerne.
Speicher ist heute so billig und so viel vorhanden und der hier geschilderte Fall tritt so selten auf auf, dass nicht wirklich erwartet werden kann, dass dafür optimiert wird.

[Gast]

Speicher ist heute so billig und so viel vorhanden und der hier geschilderte Fall tritt so selten auf auf, dass nicht wirklich erwartet werden kann, dass dafür optimiert wird.
naja...aber zumindest sollte man es anschauen können dürfen...was ja aber offensichtlich nicht geht...

die bildbetrachtungssoftware sollte wenigstens so intelligent sein aber einer bestimten bildgröße nicht das komplette bild zu dekodieren....was wirklich öhm fast erwartet werden kann, zu heutiger zeit zumindest......

[Asmodeus]

Mit Photoshop hab ich schon mal ein 600 MB TIF mit einer Auflösung von 16.000 x 16.000 öffnen können. Eine Konvertierung oder Abspeicherung war jedoch nicht möglich. Mit Paintshop konnte ich es jedoch öffnen und auch wieder abspeichern. Allerdings auf einem Rechner mit 2 GB Hauptspeicher.

Gruss, Carsten.

[Zool]

Wenn das Jpeg-Bild nicht im Progressive-Format gespeichert ist, sollte das Öffnen mit einem entsprechenden Programm schon gehen. Bei Progressive-Jpeg wird es wohl noch schwerer.

21600x21600 in 24Bit fressen auch nur schlappe 1.3GB. Da wird zum normalen Öffnen wohl nicht mal ein 2GB-Rechner reichen. Da braucht man wohl schon was besserers wie WinXP-64 oder Linux und 8GB Ram

[HeldImZelt]

Wo kriegt man denn solche Bilder? Hört sich interessant an...

[x-dragon]

Hier z.B.: http://earthobservatory.nasa.gov/Newsroom/BlueMarble/BlueMarble.html

[Muh-sagt-die-Kuh]

Ich denke nicht, dass ein allgemeines Bildbetrachtungsprogramm darauf ausgelegt ist, denn:

Normalerweise wird ein Bild beim öffnen so verkleinert, dass es auf den Bildschirm passt. Es muss also sowieso das ganze geladen und dekodiert werden.Zum verkleinern musst du das Bild nicht komplett im Speicher halten. Man kann z.B. 4 Blöcke decodieren, diese dann zu einem interpolieren und die Ursprungsblöcke wieder aus dem Speicher kicken. Jedes mal, wenn verschoben oder gezomt wird, muss zumindest neu dekodiert werden. Falls nicht ein Puffer vom File gehalten wird (würde der Forderung nach möglichst wenig Speicherverbrach widersprechen), muss sogar das File neu gelesen werden. Das erhöht extrem die Reaktionszeit des Programmes und das sehen User nicht gerne.Ein Programm kann problemlos rausfinden, ob der Speicher knapp wird....in diesem Fall kann es einfach in den Wegwerf-Modus schalten.
Speicher ist heute so billig und so viel vorhanden und der hier geschilderte Fall tritt so selten auf auf, dass nicht wirklich erwartet werden kann, dass dafür optimiert wird.Speicher kann man nutzen, so lange er vorhanden ist.....so lange das entpackte Bild kleiner als ~2 GiB ist kann das Programm das Speichermanagement dem OS überlassen, erst danach müsste es selbst intelligent wirtschaften.

[HellHorse]

...
Klar, kann man alles machen.
Bloss treten solche Fälle halt extrem selten auf. So selten, dass sie IMO vernachlässigbar sind.
Es macht wesentlich mehr Sinn, kostbare Entwicklungszeit (davon ist immer zu wenig da) zur Lösung von Problemen zu verwenden, die wesentlich häufiger vorkommen.

[HellHorse]

Hast du mir einen Link, wo ich solche Bilder zum Testen runterladen kann?
Hier:
ftp://mitch.gsfc.nasa.gov/pub/stockli/bluemarble/
gibt's leider nur solche im RAW format