Photoshop: 16 Bit-Dateien laden/speichern ist laaaangsam

[Schimmer]

Moin zusammen,

mein Photoshop braucht beim Speichern größerer Dateien unverhältnismäßig lang, wenn die Kanäle auf 16 Bit gesetzt sind.

Einige handgestoppte Messwerte dazu:

PSD-Datei mit 1 GByte, 9 Layer á 16 Bit: 1:45 min
Dieselbe Datei auf 8 Bit reduziert, 520 MB: 0:04
Dieselbe Datei mti 18 Layern á 8 Bit, wieder 1 GB: 0:25

Oder, kürzer: für das Speichern einer 1 GByte großen PSD braucht Photoshop 6 MAL SO LANG, wenn die Kanäle 16 statt 8 Bit sind.

Probiert habe ich das unter Vista 64 und Windows 7 (64) auf drei Computern mit CS3, CS4 und CS5, jeweils mit den 32er- und den 64er-Ausgaben. Unter Windows 7(64) ist CS5(64) 10 oder 15% schneller als CS4(32) oder CS5(32) unter Vista. Ansonsten liegen die Zeitunterschiede unter 5%. Der Umstieg von PSD auf PSB und/oder Abschalten der Kompatibilitätsmaximierung bringt keine messbaren Zeitvorteile.

Erstaunlicherweise fällt Google zu diesem Thema absolut nichts ein. Hat einer von euch eine Idee?

Grüße
Heinrich v. Schimmer

 

[LogBoGgED]

Hi,

das Thema ist zwar schon etwas älter, aber ich habe momentan genau das gleiche Problem und deswegen würde es mich interessieren, ob du schon neue Erfahrungen bezüglich dieses Problems sammeln konntest?

Viele Grüße
Andreas

 

[bulle.sw]

Wohl eher nicht, nachdem er vor 6 Monaten zum letzten Mal online war.

Letzte Aktivität: 24.09.2010 21:57

 

[Phei]

8-Bit: 2 hoch 8 = 256
16-Bit: 2 hoch 16 = 256 * 256 = 65536

Es sind also nicht doppelt so viele Informationen, sondern 256 mal so viel. Die werden natürlich komprimiert, dennoch ist der Aufwand für Photoshop größer.
Da kannste nix machen außer Aufrüsten, Aufrüsten, Aufrüsten. Höchstens die Cachestufen in den Einstellungen anpassen, aber das wird das Laden nicht beschleunigen, sondern nur die Aktualisierungsrate.

 

[chmee]

16Bit sind 8Bit - also 8 Nullen oder Einsen - mehr pro "Einheit" - somit von der Datenmenge nur doppelt so hoch. Die Informationsmenge ist um das 256fache gestiegen, mehr nicht. Und diese hat beim Speichern keine exponentielle Auswirkung.

Ich könnt mir vorstellen, dass 8x4 (wegen Alpha)= 32Bit/Pixel einfach nur besser mit dem Festplattensubsystem bzw Dateisystem zusammenarbeiten. Kannst Du noch nachvollziehen, welche Dateisysteme liefen? Alles NTFS? FAT32? Wenn es mögliche PSD-Kompressionsalgorithmen sind, dann müsste man das mit dem Speichern unkomprimierter TIFs verifizieren oder widerlegen können.

Wenn du photoshop 16 bit slow suchst, finden sich so einige Texte, die Meisten haben aber mit Filtern zu tun und mit der logischen Tatsache, dass 16Bit-Bilddateien in jeglicher Hinsicht mehr vom Rechner abverlangen.

mfg chmee

 

[Phei]

16Bit sind 8Bit - also 8 Nullen oder Einsen - mehr pro "Einheit" - somit von der Datenmenge nur doppelt so hoch. Die Informationsmenge ist um das 256fache gestiegen, mehr nicht. Und diese hat beim Speichern keine exponentielle Auswirkung.

Das ist mir klar, sonst wäre meine Festplatte schon lange voll. Durch mehr Bits gibt es einfach "nur" wesentlich mehr Kombinationsmöglichkeiten. Ich habe doch bewusst von Informationen und nicht von Datenmengen gesprochen

 

[BadBoogeyMan]

Aber du hast geschrieben, dass der Aufwand für PS deutlich höher ist.
Das stimmt aber nicht, der ist ziemlich genau doppelt so hoch.
Ich würde eigentlich auch behaupten, dass die Bilder auch nur genau doppelt soviel Information enthalten.

 

[chmee]

@phei: Dass jedes Bit die Genauigkeit/Informationsmenge verdoppelt, ist kein Geheimnis. Im Kontext mit der Speicherdauer macht diese Aussage aber wenig Sinn.

@BadBoogeyMan: Jaaa, aber Tatsache ist weiterhin, dass für die doppelte Datenmenge ein Vielfaches an Speicherzeit benötigt wird. Und leider keine Ahnung, woran es scheitert Wobei man auch beachten sollte, dass im eingangs genannten 8Bit-Speicherbeispiel 500MB in 4 Sekunden gespeichert werden - angeblich. Da würd ich erstmal sagen, dass die Cachingalgorithmen von Photoshop mithelfen - 125MB/sek sind nicht unmöglich, aber ein bisschen zu nahe am Optimalwert heutiger Festplatten (RAID oder SSD nicht betrachtet)

mfg chmee

 

[zerebruin]

Soweit ich das sehe hat Phei schon recht.
8 Bit = 256 Farbstufen
16 Bit = 65536 Farbstufen

Da es (bei RGB) jeweils drei Kanäle sind multipliziert sich die Farbzahl mit 3.
256*256*256 = 16,7 Millionen Farben
65536*65536*65536 = 281 Billionen Farben

Der Mehraufwand eine 16 Bit Bilddatei zu komprimieren ist also erheblich größer und dauert somit auch länger.

Probiert mal aus was für einen Unterschied es macht eine Datei als PSD oder als unkomprimiertes TIFF zu speichern, da wird klar wie Lange die Komprimierung benötigt. (Ein ZIP-komprimeirtes TIFF dauert bei mir etwa so lange wie eine PSD-Datei).

 

[Schimmer]

Erfreulicherweise verschickt das DSLR-Forum ja Nachrichten, wenn sich was tut

Zu 8 vs. 16 Bit: Jeder einzelne Wert kann 256 Mal so groß sein, korrekt. Zur Speicherung wird der doppelte Platz gebraucht, nicht der 256-Fache.
Einfacher Vergleich:
10 - zwei Ziffern/Stellen, brauchen zwei Bytes (in Unicode 4)
1000 - vier Ziffern/Stellen, brauchen vier Bytes (bzw. 8) - auch wenn es der hundertfache Wert ist.

Neuigkeiten habe ich keine, außer einen - von jemand anderem gefundenen - Hinweis auf einer Adobe-Seite: http://kb2.adobe.com/cps/404/kb404439.html

"When you save layered 16-bit or 32-bit images in the PSD (Photoshop native) file format, the compression takes significantly longer than saving flat 16-bit or 32-bit images, or 8-bit images."

Interessanterweise steht dieser Hinweis dort nicht mehr drin. Beschädigt wohl das Ansehen der Firma oder so * kopfschüttel

Meine persönliche Vermutung ist, dass die Programmierer hier wirklich nur eine Krücke eingebaut haben bei der (verlustfreien) Datenkomprimierung. (Auch wenns wohl das falsche Forum ist, sich darüber zu verbreiten: Fürs Komprimieren á la ZIP braucht man Tabellen - Stichwort: Lexika für die LZW - und die werden tatsächlich nicht doppelt so groß, wenn man von 8 auf 16 Bit umsteigt, sondern 256 Mal so groß, weil es da um Kombinationsmöglichkeiten geht.)

Was mich halt wundert: Dass sich da außer mir noch niemand so richtig drüber beschwert hat. Beim Ausprobieren war ich übrigens schon recht gründlich, unter anderem habe ich auch mal eine RAM-Disk verwendet, um das Speichermedium so weit wie möglich rauszuhalten.

 

[zerebruin]

Hi,

der Hinweis von Adobe bezieht (oder bezog) sich aber auf den Vergleich von Dateien mit Ebenen zu denen ohne Ebenen. Drei Fotos auf drei Ebenen enthalten ja (je nach Größe der Fotos) die dreifache Datenmenge.

Zum Speicherplatz: ja, da hast du recht, aber es geht ja darum wie lange Photoshop benötigt um die Kompression durchzuführen (daher mein Vergleichsbeispiel mit unkomprimiertem TIFF).
Eine 16Bit-Kompression ist eben ungleich aufwändiger als 8Bit.

 

[Phei]

Jau, das ist in etwa das, was ich mit "Aufwand" meinte. Die Größe der Datei ist wahrscheinlich eher unwichtig, es geht um die Komplexität. Der erhöhte Aufwand ist - denke ich mal - auch der Grund, warum es viele Filter nicht für 16 Bit gibt.

Ich denke, dass kann man nicht viel dran machen kann, außer halt die bekannte Aufrüstung. Ich speichere meine aktiven Projekte auf meiner SSD, habe kürzlich mal wieder einen RAM-Riegel nachgeschoben und finde es auch bei großen 16-Bit Panoramen damit angenehm.

Ich bin mir sicher, dass hier bald ein Informatiker auftauchen und uns alle aufklären wird.

 

[Hoogo]

Habe mal einen Vergleich in PL gemacht, 3 Ebenen, knapp 900MB bei 16Bit unkomprimiert:
16 Bit, 500 MB, 75 Sekunden
8 Bit, 250 MB, 25 Sekunden

Die verwendete Png-Kompression braucht auch hier bei 16Bit über das Verhältnis länger, wenn auch nicht so extrem.

Mich verblüffen eher die 4 Sekunden des TO bei 8Bit. Das dürften doch unkomprimiert immer noch 1GB sein, und das soll in 4 Sekunden komprimiert und gespeichert sein? Da läuft doch bestimmt noch was im Hintergrund...

 

[Gelöschtes Mitglied 56390]

Mich verblüffen eher die 4 Sekunden des TO bei 8Bit. Das dürften doch unkomprimiert immer noch 1GB sein, und das soll in 4 Sekunden komprimiert und gespeichert sein? Da läuft doch bestimmt noch was im Hintergrund...

Das Geheimnis von Photoshop dürfte sein, daß hier nicht großartig komprimiert wird.

Photoshop Elements war schon immer wesentlich schneller als PhotoLine beim Laden und Speichern. Dafür waren die PLD-Dateien von PhotoLine immer so um die 60% kleiner als die PSD-Dateien von Photoshop Elements.

Das zieht sich bei Elements wie ein roter Faden durch das ganze Programm, es läuft schneller, braucht aber enorm Speicher. Sowohl RAM beim Bearbeiten, als auch auf der Festplatte beim Speichern. Bei Photoshop dürfte es ähnlich sein.

Wobei PhotoLine aber auch ungepackt nicht an die Geschwindigkeit von Elements beim Speichern rankommt. Aber dafür habe ich halt mehr Platz auf der Festplatte, ist auch nett.

 

[chmee]

Habe Hier eine Beschreibung des PSD-Dateiformats gefunden. Eine Möglichkeit, herauszufinden, ob es vielleicht darin zu finden ist. Eine simple Antwort könnte sein, dass sich optimierter 32Bit-Code wie Kaugummi durch das ganze Programm zieht - ergo keine/kaum Optimierung für 64Bit-Chunks.

..planar order.. first, all red data, then all green data..

Ein 8Bit-Pixel hat nunmal 24Bit Farbdaten, ich gehe davon aus, dass ein möglicherweise bestehender Alphakanal oder eine Ebenenmaske einzeln gespeichert wird (siehe PDF oben, Colormode-Section und Mask Information Section) 24Bit sind super mit einem optimierten 32Bit-Befehl abarbeitbar - egal ob Lesen/schreiben oder Kompressionsmodule - im besten Fall sogar in einem Takt. Dagegen müssen 48Bit (3x16Bit) in mehrere Befehle zerlegt werden, im scheinbar schlimmsten Fall wird es also nicht nur ein optimierter SSE2-Befehl, sondern unoptimiertes mehrtaktiges Bla. Da geht dann ganz viel Power verloren.

Aufschluss würde geben, wenn man beim Speichern das Verhältnis CPU- zu Dateischreiboperationen verfolgt. Wieviel Zeit/Ressource wird von welchem Bauteil in Anspruch genommen.

mfg chmee

 

[Schimmer]

im scheinbar schlimmsten Fall wird es also nicht nur ein optimierter SSE2-Befehl [...]

Aufschluss würde geben, wenn man beim Speichern das Verhältnis CPU- zu Dateischreiboperationen verfolgt. Wieviel Zeit/Ressource wird von welchem Bauteil in Anspruch genommen.

SSE2 glaube ich nicht so recht. Wir haben es hier ja mit einer verlustfreien Komprimierung zu tun (LZW), und nicht mit JPG&Co (Fourier und ICDT - da machen die sich ja sehr gut). Ich vermute sehr stark, dass da irgendwer den ganz einfachen Weg gegangen ist - so á la: "Wenn die R-Plane nicht als 8-Bit-Chunk verfügbar ist, dann sammeln wir sie eben pixelweise ein, am besten noch über einen Makro, der das höchst elegant wieder in 8 Bit liefert, nur eben doppelt so oft - und kein Schwein hat gemerkt, dass der Makro jedes Byte 5 Mal evaluiert"

Ring 3 vs. Kernel bzw. Disk I/O im Performance Monitor, damit ließe sich das rauskriegen, da stimme ich dir zu.

Ich bin mir sicher, dass hier bald ein Informatiker auftauchen und uns alle aufklären wird.

Och...

 

[chmee]

In der PDF zum Aufbau ist beschrieben, welche Kompressionen benutzt werden dürfen. Und es muß nicht komprimiert werden..

SSE2 ist verpflichtend seit CS2 - nur ist das nicht mehr besonders interessant, da es keine CPUs mehr ohne gibt So kann man nicht mehr unterscheiden, welche Libs/Module/Codefetzen darauf zugreifen und welche nicht. Schimmer, genau so einen 16Bit-Flickenteppich-Sourcecode vermute ich auch

Naja, dann warten wir mal schön auf den Informatiker..

mfg chmee

 

[Schimmer]

SSE-2 ist Pflicht, klar. Nur denk ich, dass es da um die Filter geht, nicht um die Komprimierung. Wissen tue ich das natürlich nicht, und außerdem sind Informatiker ja eh doof

Ich habs jetzt mal endlich bei Adobe reingestellt - mal gucken, was da kommt:

http://forums.adobe.com/message/3592069

 

[LogBoGgED]

Hi Leute,

erstmal vielen Dank dass sich hier so viele Leute noch an dem Thema beteiligt haben. Das bringt die ganze Diskussion etwas voran und vielleicht findet sich in nächster Zeit ja noch eine "Lösung" für das Problem.

Ich werfe hier mal ein paar technische Daten ein:

ich habe:
- einen Xeon Nehalem Quad-Core mit 2.8 Ghz
- 16 GB DDR3-Ram (4x4 GB)
- eine Radeon 5770
- für OS und Programme eine WD Velociraptor 300 GB
- für Bilder eine 1.5 TB WD
- und für Daten und Auslagerung eine 1 TB WD

Das Speichern einer ca. 800 MB großen PSD mit 3 Layern dauert bei mir 1 Min. 9 Sek.

Das Gleiche bei 8 Bit dauert hingegen nur 4 Sek.

Die Datei bei 8 Bit wieder auf 800 MB gebracht dauert 11 Sek.



Das Starten meines Rechners geschieht übrigens innerhalb von 10 Sek. und das Laden von Photoshop in nichtmal 3 Sek.
Dass zwischen dem Speichern von 16-Bit-Dateien in Photoshop und allen anderen Prozessen ein so großer Abgrund liegt, hätte ich nicht gedacht :-(

Bevor ich mir diesen neuen Rechner zugelegt habe, hatte ich ein RAID-0 mit 2 x 750 GB, das waren auch WD-Platten. Da kam es mir gefühlt so vor, als ob das Speichern im Nullkommanix vonstatten ging. Bei 8 Bit hatte ich NIE irgendwelche Verzögerungen und ich muss dazu sagen, dass ich sehr oft mit 1 bis 2 GB großen Dateien arbeitete und immer noch arbeite.
Frühe hatte ich auch die ein oder andere 16-Bit-Datei gespeichert und da hat es sicherlich nichtmal ne Minute gedauert.

Kann eurer Meinung nach das RAID-0 eine solche Performance-Steigerung bringen oder meint ihr dass es an etwas anderem liegt, möglicherweise eine falsche Einstellung am OS oder von Photoshop?

Viele Grüße
LogBoGgED

 

[chmee]

Ein RAID0 kann bis zu doppelt so schnell wie eine HDD sein, das ist erstmal ein Unterschied. Ein weiterer könnte das OS sein, was wurde zuvor benutzt, welches OS läuft jetzt. Wieviel RAM hattest Du im "alten" Rechner drin. Wie waren/sind die Caching-Einstellungen von Photoshop.. etc pp

Es ist natürlich müßig mit einer Ferndiagnose ad hoc die Ursache zu finden.

mfg chmee