64-Bit-Bildbetrachtungsprogramm?

[Saugbär]

Irfan View war mir bisher ein treuer Helfer beim Betrachten und Zoomen von normalen Bildern. Bis 100 MegaPixel habe ich auch keine Probleme.
Da jedoch die Digitalkameras mit immer höheren Auflösungen (> 20Mp) im Kommen sind, habe ich Probleme bei großen Bildern.
Anbei mal ein Beispiel eines 260 Mp Bildes. Es verbraucht ca. 750 MB Arbeitsspeicher. Beim Zoomen steigt jedoch der Speicherverbrauch auf über 1.5GB, man kann danach zwar noch bis auf Pixelebene heranzommen, aber ein verkleinern ist nicht mehr möglich, da ein 32Bit Programm ja max 2GB verwalten kann.
Gibt es eine möglichst kostenlose 64Bit Alternative?

[Gast]

Die Alternative wäre die .exe patchen damit sie auch mit dem Speicherbereich bis 4GiB umgehen kann, das würde das Problem zumindest deutlich lindern.

[DanMan]

Fast Picture Viewer (http://www.fastpictureviewer.com/formats/)

Wie man sieht kann die Freeware-Version nur JPGs lesen. Das aber wirklich in einen Affentempo.

[HisN]

xnview (http://www.start64.com/index.php?option=com_content&task=view&id=2597&Itemid=72)

[Schimi1983]

paint.net (http://www.getpaint.net/)

kann ich nur empfehlen


ist zwar kein reiner Bildbetrachter aber vielleicht ne alternative

[(del)]

Fast Picture Viewer (http://www.fastpictureviewer.com/formats/)

Wie man sieht kann die Freeware-Version nur JPGs lesen. Das aber wirklich in einen Affentempo.An sich schon, aber keine Thumbs-Übersicht? :|

http://vimeo.com/6209887

@Saugbär
Es sind keine >20MP Knipsen im Kommen.

Wo hast du die 260MP Bilder her? :)

[sun-man]

Also der FastStone Imageviewerr kann das sehr fix, ist nur nicht so einfach fürs reine anglotzen wie Irfan.

[Saugbär]

Zwischenbericht:
Mit xnview konnte ich das Bild einmal öffnen, jetzt gibt es eine Fehlermeldung "Nicht genügend Arbeitsspeicher".:freak:
Paint.net hat sein Limit wohl bei 4GB Zoom ist nur bis 203% möglich. Bei kleineren Bildern sind alle Zoomstufen verfügbar.
Irfan Viewer steigt auch mit der Fehlermeldung "Zu wenig RAM Speicher für Bild(er) vorhanden !" aus.
Die Windows Fotoanzeige ist ungeeignet, da es ungefragt beim Bild drehen einfach abspeichert und damit das Bild verändert.

Zum System:
CPU Q6700 @3200Ghz
Win7 x64 8GB Ram + 16GB Auslagerungdatei.
Auch der freie Festplattenplatz mit ca 1TB sollte ausreichend sein

[Detritus]

Ich habe leider kein Bild in dieser Grösse um es auszuprobieren, aber mein Lieblings-Bildbetrachter ist seit Ewigkeiten das 2005 eingestellte Slowview (900kB) (http://www.chip.de/downloads/SlowView-1.0-RC2_13001732.html); auch unter Win7-64bit. Probier's doch damit mal aus oder sag' mir, wo ich ein so grosses Bild finde, damit ich es mal testen kann.

edit: das 82MP-Bild (http://collections.alexandria.ucsb.edu/ap/indexes/nasamsc128bsites29and225flt2r10/), das ich auf die Schnelle fand, bläht slowview von 1,5 auf 160MB-Speicherbedarf auf. Drehen, beschneiden, zoomen geht problemlos.

[(del)]

edit: das 82MP-Bild (http://collections.alexandria.ucsb.edu/ap/indexes/nasamsc128bsites29and225flt2r10/), das ich auf die Schnelle fand, bläht slowview von 1,5 auf 160MB-Speicherbedarf auf. Drehen, beschneiden, zoomen geht problemlos.Das sind aber eben keine ~"260MP". Faststone lacht sich über das Bild unter XPsp3/3GB halbkaputt.

[HeldImZelt]

Hier sind synthetische 4.2GP (Gigapixel) Bilder. Ich habe es nie geschafft die größten Bilder unter 32Bit zu laden. Theoretisch könnten die Programme ja "nachladen".
http://www.abload.de/img/65535tcr2.png

[WEGA]

die synthetischen bilder gefallen mir.
kann man mit win7 64bit und "windows fotoanzeige" problemlos ansehen, solange der RAM reicht.

[HeldImZelt]

12GB Ram (besser 16GB) sollte man schon haben für 65k^2 (12.884.901.888 Bytes).

[Saugbär]

Hier sind synthetische 4.2GP (Gigapixel) Bilder. Ich habe es nie geschafft die größten Bilder unter 32Bit zu laden. Theoretisch könnten die Programme ja "nachladen".
http://www.abload.de/img/65535tcr2.png
32 Bit geht nur bis max 2GB pro Datei, da nutzt virtueller Speicher auch nichts, danach kommt out of memory.

Mit deinen synthetischen Bildern ich ja mal testen.
Bei einem Teil der .jpg Bilder ist mein Virenscanner angesprungen. Es wurde ein Virus oder unerwünschtes Programm 'EXP/MS04-028.JPEG.C' [exploit] gefunden. Betroffen sind die Dateien 01 bis 09. Fehlalarm?

So jetzt mal zum Speicherverbrauch:
Ein 4Gigapixel großes Bild verbraucht ca 320GB virtuellen Speicher, da sind selbst 24GB Ram nur ein Tropfen auf den heißen Stein.
Das laden selbst dauert je nach Hardwareaustattung mindestens 10 Minuten.

Das Speichern von einem 1 GP Bild unkomprimiert belegt ca 24!!!GB Festplattenplatz.
Für ein beschleunigtes Arbeiten mit solchen Datenmengen wäre Sata3 im Raidverbund mit 2 SDD Festplatten im Moment die einzige kostengünstige Möglichkeit.

[HeldImZelt]

32 Bit geht nur bis max 2GB pro Datei, da nutzt virtueller Speicher auch nichts, danach kommt out of memory.
Er muss ja nicht das ganze Bild auf einmal prozessieren, nur quasi on-demand Bereiche, daher sagte ich ja "nachladen". Alles eine Frage der Technik. ;)

Bei einem Teil der .jpg Bilder ist mein Virenscanner angesprungen. Es wurde ein Virus oder unerwünschtes Programm 'EXP/MS04-028.JPEG.C' [exploit] gefunden. Betroffen sind die Dateien 01 bis 09. Fehlalarm?
Ja, Fehlalarm. Die Kopfdaten signalisieren einen größeren Speicherbereich als im eigentlichen Body der Datei zugeordnet wird. Durchaus eine gängige Exploittechnik.

So jetzt mal zum Speicherverbrauch:
Ein 4Gigapixel großes Bild verbraucht ca 320GB virtuellen Speicher, da sind selbst 24GB Ram nur ein Tropfen auf den heißen Stein.
Das laden selbst dauert je nach Hardwareaustattung mindestens 10 Minuten.

Das Speichern von einem 1 GP Bild unkomprimiert belegt ca 24!!!GB Festplattenplatz.
Da würde ich aber nochmal nachrechnen...

[Saugbär]

Da würde ich aber nochmal nachrechnen...
da hast du Recht, es waren 4 GP Gigapixl (http://www.gigapxl.org/faqs.htm)

[HeldImZelt]

Rechne mal vor, wie du auf 320GB Speicherverbrauch kommst.

[PHuV]

Hier stand Unsinn.

[(del)]

Er muss ja nicht das ganze Bild auf einmal prozessieren, nur quasi on-demand Bereiche, daher sagte ich ja "nachladen". Alles eine Frage der Technik. ;)Eigentlich wünscht man sich meistens das Bild zuerst auf Bildschimrgröße zu skalieren ;)

[HeldImZelt]

Nicht wirklich ein Problem. Das große Bild wird immer nur teilweise "entpackt", sagen wir in 2000x2000 Blöcke, runterskaliert und als Fragment in das Ausgabebild gesetzt, solange bis alle Teile abgearbeitet sind.

@Saugbär:
Rechnest du noch oder willst du nicht erläutern wie du auf 320GB kommst?

[(del)]

Ich weiß wie das bereits gemacht wird ;) Es ist nur die frage wie lange das dauert und wann dem System alle RAM-Beihilfen ausgehen.

Deine custom jpegs hat der FSV 4.1beta hier entweder fehlerhaft dargestellt oder problemlos. Jedenfalls dauerte es nur Sekunden und alle Angaben in den eigenschaften des Bildes stimmen. Auf 3GB XPsp3 an sich nicht wirklich real world. Da müßte es mehr Probleme geben. Bei manchen riesigen TIFFs der NASA jongliert er sich halbtot.

[HeldImZelt]

Ich weiß wie das bereits gemacht wird ;) Es ist nur die frage wie lange das dauert und wann dem System alle RAM-Beihilfen ausgehen.
Bei Teilprozessierung steigt der Ramverbrauch nicht, egal wie groß das Bild ist. Die Ressourcen können (in diesem Fall) nicht ausgehen. Man braucht nur zwei Buffer, 2k² Arbeitsbereich und Ausgabebuffer (Desktopauflösung). Lediglich der Programmieraufwand ist höher und der Dekodierprozess dauert etwas länger (zu vernachlässigen). Ich kenne bisher kein Programm, dass das macht. FSV habe ich noch nicht getestet. Die Bilder habe ich damals erstellt, um den Firefox auszuloten. Dafür hat's gereicht...

[Saugbär]

@Saugbär:
Rechnest du noch oder willst du nicht erläutern wie du auf 320GB kommst?
Sobald ich den Link wiederfinde.
Wieso können einige professionelle Programme deine Beispielbilder überhaupt nicht öffnen?
Adobe Photoshop meldet:"Der Vorgang konnte nicht ausgeführt werden, weil die Länge eines JPEG-Markersegments zu kurz ist (die Datei ist eventuell abgeschnitten oder unvollständig)
BMP und PNG wird ebenso verweigert.

[HeldImZelt]

Wieso können einige professionelle Programme deine Beispielbilder überhaupt nicht öffnen?
Weil sie eigene Fileparser und Dekoder haben, die nicht annähernd so fehlertolerant sind wie die windowseigenen Funktionen. Vielleicht funktionieren andere Formate besser (GIF, TGA, TIFF..).

Die größten Bilder brauchen 65535*65535*24/8=12.8GB Ram. Es gibt auch nur sehr wenige und exotische Formate, die mehr als 32bit Pixel (quantitativ) erlauben. Eines davon ist PSB (Photoshop Big) (http://de.wikipedia.org/wiki/PSB_%28Dateiformat%29). Da würde man bei 300k² (90 Gigapixel) auf 270GB (8bpc) und 540GB (16bpc) Datenaufkommen stoßen.
8bpc = 8 Bits Per Channel * 3 color channels (RGB) = 24bit.
Am gebräuchlichsten ist der RGB-Farbraum mit 8 Bit pro Kanal, entsprechend (2^8)^3 = 16.777.216 (ca. 16,7 Millionen) theoretisch möglichen Farben. Bei 16 bit (pro Kanal) resultieren daraus bereits 281474976710656 (ca. 281 Billionen) Farbmöglichkeiten.
http://de.wikipedia.org/wiki/Farbtiefe_%28Computergrafik%29

[Gast]

Es ist zwar kein Bildbetrachtungsprogramm, aber Gimp benutzt die Festplatte, wenn der RAM nicht mehr ausreicht.

Mußt jetzt nur ne 64 Bit Gimp Version nehmen.
Am besten gleich Linux dazu, dann werden nicht gleich 4 GB RAM an das OS verschwendet.

[sun-man]

Hmm ? gerade Linux macht doch zum Glück reichlist Gebrauch vom Ram. Zum Glück.

[Gast]

Hmm ? gerade Linux macht doch zum Glück reichlist Gebrauch vom Ram. Zum Glück.

Aber nicht so wie du denkst.
Es geht um den Platz, der von userspaceprogrammen reserviert werden kann.
Bei Windows ist das fest.
Das nimmt sich 4 GB, siehe auch der Screenshot mit dem Task Manager.
Er hat 8 GB RAM, aber nur 4 GB kriegt er für alle seine Anwendungen.

Bei Linux kann man das wenigstens Variabel anpassen, im Worst Case Fall muß man nur den Kernel neu kompilieren.

[Gast]

Mit 64bit-Windows bekommen die Anwendungen natürlich mehr als 4GiB. (Eine einzelne Anwendung logischerweise nur wenn sie selbst eine 64bit-Anwendung ist)