Hallo zusammen,

ich habe mir eine 70D gekauft. Ich fotografiere im RAW-Format. Leider dauert es bei meinem MacBook Pro (Mitte 2012, 2,3 GHz, 16GB RAM) zirka 10-15 Sekunden bis ich ein Bild im Finder per Vorschau (Leertaste) angezeigt bekomme.

Ich mein, jedes Bild ist zirka 30MB groß - verständlich dass da einiges an Daten geladen wird. Mich würde es einfach interessieren ob das eine normale Zeitspanne ist und ob es Möglichkeiten gibt, wie sich die Bilder schneller öffnen lassen würden...

Wenn man mehrere Bilder anschauen will, zieht sich das mitunter ziemlich hin...

Danke und Grüße
howsy

Was hältst du von einer SSD?

256GB SSD ist schon drin. Direkt von Apple halt...

Ich meine gelesen zu haben, wenn man das Programm "Vorschau" mit Apfel+I öffnet und dort "Niedrig aufgelöst öffnen" aktiviert, soll alles schneller sein. Bei mir ist es zwar nicht schnell, aber nach 0,5 - 1 Sekunde sehe ich alles, daher hab ich es auch nicht ausprobiert. Ob das bei Nicht-Retina MacBooks überhaupt diese Option gibt, weiß ich nicht.

Gruß
Richard

Mit meinem Mac Mini C2D 2,53 GHz: 15 MB Canon RAW von HD(!) unter Snow Leopard: 1-2 Sek., unter Mavericks (selbst von SSD) wesentlich länger!
jpg geht unter Mavericks etwa gleich schnell wie SL. Liegt wohl am RAW-Format.

Falls das Raw Format Update auf dem neuesten Stand ist und auch Richards Tipp nicht geholfen hat, kann man es noch mit dem Löschen der Quick Look Voreinstellungen versuchen (usr/Library/Preferences/com.apple.QuickLookDaemon)...
Glaube aber vor kurzen in den Apple Discussion Groups gelesen zu haben das dieses Verhalten wohl ein unregelmäßig auftretender Bug von Quick Look ist...

Das RAW Format von Apple ist auf dem neusten Stand, sowie auch das Camera Raw 8.3 Update von Adobe ist drauf. Ich habe die Quick Look Voreinstellungen gerade gelöscht, scheint aber nichts gebracht zu haben.

Was meinst du mit "unregelmäßig auftretender Bug"... Im Sinne von "tritt ab und zu beim gleichen Notebook auf" oder "tritt bei einigen Benutzern auf" ?

Bei mir hat nach dem Upgrade nach Mavericks auf meinen Zweitrechner der Finder gezickt - bei der Lösungssuche in den Discussion Groups las ich dann eher nebenbei von den Quick Look Problemen…Diese traten nach dem Upgrade bei einigen Nutzern auf, auf verschiedenen Rechnern…Was ich merkwürdig fand war das diesen recht unterschiedliche Dinge Erfolg brachten - vom Löschen der QuickLook Caches und Einstellungsdateien über das Löschen der Finder Einstellung und Safe Boot bis hin zu einem smc Reset (der hat meinen Finder damals geholfen)…
Falls niemand anderen noch etwas einfällt, diese zwei Threads hab ich mir damals 'aufgehoben'

Mal andre Frage, wie alt ist dein System?

Ich hab meinen jetzt mal neu Aufgesetzt von Hand. Das System war schon gut 6 Jahre alt, hab immer nur Update gemacht, oder alles wieder von TimeMaschine geholt. Jetzt ist er spürbar schneller.

Das mag sich jetzt zwar komisch anhören, aber irgendwann um die Jahrtausendwende hat Os X (damals die Public Beta) das klassische OS 9 abgelöst - Ne zeitlang hab ich parallel gearbeitet bis dann so nach und nach alle mir wichtigen Programme auf X liefen…
Ich hab seitdem mein System nie neu eingespielt, sondern jeweils die neueste Version darübergebügelt. Bei Rechnerumzügen hat meist CCC und ab und an der Migrationsassistent geholfen. Bei meinen Hauptrechner (momentan ein i7 mini) gehörte ich aber nie zu den Early Adopters - Dafür gibt es noch ein betagteres MacBookPro mit Core2Duo…
Entgegen aller Vernunft hat das all die Jahre zumeist problemlos geklappt (TinkerTool hat hier recht gute Dienste geleistet um alte und verwaiste Daten zu finden und zu löschen)...

Ich habe meinem Mac Mini C2D 2,53 GHz mit Mavericks gestartet (Clean Install, nur wenige Testprogramme): 15 MB Canon RAW von HD in Quicklook 4-6 Sek. pro Bild, unter Snow Leopard 1-2 Sek.
Die hier gerne gemachten Vorschläge "mehr RAM, SSD" helfen nicht wirklich gegen mäßige Programmierung.
Einer der Gründe, warum ich derzeit noch bei SL bleibe.

zephirus: vielen Dank für die Links, werde ich ausprobieren sobald ich wieder meinen Mac in Reichweite habe

Gerry: ich habe mein System noch nie selbst neu aufgesetzt. Immer nur die Updates von Apple gemacht. Ein komplettes Neuaufsetzen ist im Kopf vermerkt, würde nur gerne erst ein paar andere Sachen ausprobieren als direkt mit dem Dampfhammer drüber zu bügeln...

Wenn der "Safe Boot" (der ja einige Caches abräumt) nicht hilft, würde ich mal ExactImage ausprobieren: http://rene.rebe.de/2013-08-11/exactimage-quicklook-w-camera-raw-support/

Und in den CrashReporter-Ordnern (im Benutzerordner und global Library/CrashReporter) nach QuickLook Prozesse Ausschau halten. Evtl. crasht der Hintergrundprozeß bei Dir ein- oder sogar mehrfach je Bild (alles schon gesehen)

Wenn's anschl. genauso lahm ist, dann hat's was mit "QuickLook an sich" zu tun ansonsten mit dem CameraRaw-Paket von Apple.

Würde ich auch nicht ohne Not. Ich ziehe seit System 8.0 nur um, seit 10.3.4 konsequent per Migrations Assistent. Keine Probleme (bzw. werden die nicht mit dem Dampfhammer kaschiert sondern wenn dann gelöst )

Noch 'ne Anmerkung, die ich vorhin unterschlagen hatte, da auf dem Sprung gewesen. QuickLook basiert ja auf einem Plugin-System. Neben Apples eigenen QL-Generatoren kann beliebige 3rd-Party-Software auch sowas mitbringen (ggf. mehrere Plugins, die sich für identische Dateitypen -- konkret UTIs zuständig fühlen. Einen Überblick, was alles im System aktiv ist, kriegt man im Terminal per


Und um rauszufinden, was bei QuickLook ggf. lähmt, hilft abermals qlmanage:


(am Besten im Terminal "qlmanage -p -d1 " -- ohne Anführungszeichen aber mit abschließendem Leerzeichen -- tippern und dann aus dem Finder eine Datei, die einen interessiert per Drag&Drop ins Terminalfenster ziehen. Dann drücken und in Terminal sieht man, welchen UTI die Datei hat, welcher QL-Generator zuständig ist und ob evtl. Verzögerungen daran liegen, dass QL ein Problem hat oder einfach nur das Laden der Datei ewig dauert (Indiz dafür lange Verzögerung zwischen den letzten beiden Zeilen der Debug-Ausgabe). Man kann mittels qlmanage auch gezielt QL-Caches abräumen als auch beim Untersuchen einer Datei gezielt UTI oder QL-Generator vorgeben: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/qlmanage.1.html

So, ich saß gestern noch eine Weile dran. Es hat alles nichts genützt. Schlussendlich habe ich tabularasa gemacht und den Rechner neu aufgesetzt. Auch das blieb ohne Erfolg.
Ich habe gestern dann gleich mal einen Bug-Report bei Apple aufgemacht, der auch prompt als "Dublikat" geschlossen wurde. Jetzt mal schauen was dabei raus kommt. Bei Apple scheint es ja ein bekanntest Problem zu sein...

Hast Du den Fall-Link? Weil ich habe auch lags bei quicklook, egal welches Format.
Danke!

der_seppel

Das hier ist die Bug-Nummer: 14987413

Deine (duplicate) oder das "Original"? Weil hier findet sich dazu leider nix:

Was ist openradar? Ich habe eine Bug bei Apple eingestellt... unter bugreport.apple.com...
Das ist die Nummer vom "Original Bug".

Ein "Community Projekt" von OS X/iOS-Entwicklern, die es leid waren, dass ihre Bug-Reports entweder unbegründet (und ab und an fälschlich) als "duplicate" abgelehnt wurden oder aber die erstmal gucken wollten, ob das Problem nicht evtl. schon gemeldet war. Auf Apples eigene Bugreport-Datenbank hat ja kein Externer Zugriff. Und besagtes openradar-Projekt lebt nur und ausschließlich von der Teilnahme. Und leider hat derjenige, der den "Original Bug" eingereicht hat, versäumt, den Bug auch in openradar abzukippen.

Na, dann stell ich den halt auch da ein... Ist ja kein Thema... Ich poste dann nachher die Bug-ID

Ich hab meinen Status jetzt eingetragen:
http://openradar.appspot.com/15961257

Bei mir scheint es hier Probleme zu geben.
"[DEBUG] file:///Applications/GarageBand.app/Contents/Library/QuickLook/GarageBandQLGenerator.qlgenerator/ overrides <QLGenerator /Library/QuickLook/GBQLGenerator.qlgenerator>"

Sehe ich das richtig: Es sind zwei Generatoren vorhanden, einer im Programmpaket und einer in der Library? Werde den in der Library mal lösch und schauen wie es sich auswirkt.

Ja. Aber das ist eigentlich auch kein Problem. Es "gewinnt" der QLGenerator mit der frischeren Version (CFBundleVersion) und der andere ist inaktiv. Sollte auch bei Dir der Fall sein (alles in einer Zeile):


Das dürfte nichts ändern, denn der ist eh inaktiv. Das Ganze ist eigentlich nur wichtig, wenn man nachgucken will, welcher konkrete QLGenerator überhaupt zum Zug kommt. Weil evtl. ist da einer an Bord, der zwar eine hohe Versionsnummer hat aber nach einem Systemupdate bspw. inkompatibel ist, dann den Zuschlag bekommt, wegcrasht und dann -- reine Annahme meinerseits -- der andere erst zum Zug kommt. Ob's so einen Fallback gibt, weiß ich nicht, könnte ich mir aber vorstellen. Sollte im Zweifel auch die ganze Ausgabe von "qlmanage -p -d1" hergeben...

Konnte auch keinen Unterschied feststellen. Tragisch langsam ist es nicht. Kurze Verzögerungen. Mavericks ist halt noch ein wenig zäh
Vielleicht bessert sich das mal später.

Ich beobachte auf meinem neuen iMac i7 von vorgestern kaum Verzögerungen mit jpg-Dateien, mit Sony Raw-Dateien (ca. 35 MB gross) dauert es aber durchaus ein paar Sekunden. Die Grösse kann's aber nicht sein, denn unter 10.6.8 braucht dieselbe Datei auf einem 4-jährigen iMac i7 halb so lange.

Das Terminal spuckt mit der jpg-Datei folgendes aus:


Mit der Sony-Datei:


Die "Denkpause" findet während oder nach der letzten [DEBUG]-Zeile statt.

Ich hab mir das eben auch nochmal in 10.9.1 angeschaut. Das "Problem" hier ist, dass ich Mavericks bislang nur virtualisiert im Zugriff habe, und da dann gleich so viele OpenGL-relevante Fehlermeldungen aufpoppen, wenn man QuickLook mit Bildern nutzen will, dass ich erstmal gedacht hab, das wäre evtl. mit verursachend, siehe bspw. . Das ist das, was in /var/log/system steht, wenn ich QuickLook für ein Canon-RAW aufrufe. Gleiche ewige Verzögerung hier, ca. 7 Sekunden. Und im Log heißt's: "UI updates were finally reenabled by application "Finder" after 6.65 seconds" -- ich hab aber keine Ahnung, ob das nicht wegen meiner nicht offiziell unterstützten Virtualisierungsvariante auftaucht).

Aber hier identisches Bild: qlmanage -d1 meldet bereits "Previewing file://... finished", dann passiert lange nichts und dann kommt das Bildchen. Unter der Haube geschieht die ganze Warterei zwischen Zugriff auf QuickLooks Cache.db (wohl ein Lookup, ob da schon eine noch valide Preview drin steckt) und dem Zugriff auf mdsObject.db durch den talagent (der wird aber erst aufgerufen, wenn alles fertig ist):

http://pastebin.com/4Uk7qcRu

Weiteres Nachgucken mit DTrace war auch nicht sonderlich erhellend (auch wenn's bisschen Richtung Interprozeß-Kommunikation und sandboxd zeigt -- das ist ja ein löbliches Verhalten, Bildformate möglichst in komplett isolierten Prozessen zu rendern, denn immerhin sind Exploits über manipulierte Mediendateien der Liebling aller Krimineller, Strafverfolgungsbehörden und Geheimdiensten).

Wie auch immer, das Problem wohnt wohl in Mavericks selbst und ist kein individuelles Fehlverhalten. Warten auf Systemupdate

Hier sind es auch etwa 7 Sekunden für ein RAW auf dem neuen Mac Pro.
Liegt sicher an 10.9.1
System 9.1 war doch damals auch fast am Ende, da kam nur noch 9.2.1

qlmanage -p -d1 //Till\ Bildspeicher\ Plus/Schneemotive/Capture/Schneemotive_0008.CR2
Testing Quick Look preview with files:
//Till Bildspeicher Plus/Schneemotive/Capture/Schneemotive_0008.CR2
[DEBUG] Preview test for file:///Till%20Bildspeicher%20Plus/Schneemotive/Capture/Schneemotive_0008.CR2. Content type UTI: com.canon.cr2-raw-image
[DEBUG] Previewing file:///Till%20Bildspeicher%20Plus/Schneemotive/Capture/Schneemotive_0008.CR2. Content type UTI: com.canon.cr2-raw-image. Generator used: <QLGenerator Image.qlgenerator>
[DEBUG] Loading <QLGenerator Image.qlgenerator>
[DEBUG] Previewing file:///Till%20Bildspeicher%20Plus/Schneemotive/Capture/Schneemotive_0008.CR2 finished
2014-02-17 10:27:30.683 qlmanage[680:507] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0xc423, name = 'com.apple.tsm.portname'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2014-02-17 10:27:30.684 qlmanage[680:507] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0xc837, name = 'com.apple.CFPasteboardClient'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2014-02-17 10:27:30.685 qlmanage[680:507] Failed to allocate communication port for com.apple.CFPasteboardClient; this is likely due to sandbox restrictions

Danke fürs Forschen. Der Cache kann's kaum sein, denn die Verzögerung ist immer etwa gleich lang, egal ob es eine neue oder schon betrachtetet Datei ist. Und mit jpgs tritt das Problem ja nicht auf.

Der Cache ist es auch nicht. Es betrifft "nur" die Verzögerung der Darstellung, die eigentliche Preview-Generierung geschieht nämlich affenschnell auch bei fetten RAWs (vor allem wenn 'ne SSD drunter ist, weil sich dann mal die Dauertransferraten real auswirken).

Man kann Quicklook und auch Spotlight ja prima für dies&das "mißbrauchen" (wir benutzen das in Kundenprojekten, um blitzschnell hochqualitative Previews von Dateien in Mediendatenbanken zu kippen bzw. Volltextindizierung und sowas). Wenn ich bspw. für dieses 40 MByte große RAW-File das da absetze:


dann rendert mir OS X in 0,36 Sekunden aus einem 40 MByte großen RAW eine max. 1024x1024 PNG-Vorschau in Top-Qualität (Details siehe http://pastebin.com/2AXyZ0ps. Auf einem popeligen Mini in einer virtuellen Maschine mit nur 2 zugewiesenen CPU-Cores und 4 GByte RAM ohne OpenGL/OpenCL-fähige GPU (weil die GPU reicht ESXi, das direkt auf dem Mini läuft, nicht in die VM durch).

Ich find das einerseits beeindruckend schnell, grad wenn man mit Preview-Generierung für RAWs auf anderen Plattformen vergleicht. Und deshalb es gleich "umso lustiger", dass aktuell noch ein Bug in 10.9 steckt, der dann nach Vorschauerzeugung in Rekordzeit eine sensationell lange Tiefschlafphase einlegt, um das Ergebnis dann erst dem Anwender zu präsentieren

Geschieht übrigens auch, wenn man die wie oben erzeugte Preview dann aus dem Terminal heraus in Preview.app öffnen will. Nach Absetzen von dauert's auch paar Sekunden, bis sich dann das vorher in Rekordzeit erstellte Bildchen in Vorschau öffnet. Da klemmt irgendwas noch an der interprozeß-Kommunikation...

Vielleicht gehört dieses Phänomen in die gleiche Kategorie (zu frisches Mavericks):
Man öffnet eine Datei auf dem Schreibtisch. Eine halbe Sekunde Später wischt noch eine Animation hinterher obwohl die Datei schon geöffnet ist. Manchmal, aber nicht immer. Seltsame Sache.

Hier sieht es mit 10.9.2 so aus als wäre der unsägliche Quicklook-Bug beseitigt.
Sehr schön!

Bei meinem eher schlappen MacBook Air hat 10.9.2 diesen Bug auch behoben

Wenn du 10.9.x verwendest, ist das wohl noch ein Bug.

Oh, bmonno schrieb, dass das Update auf 10.0.2 diesen Fehler behoben hat.

Tatsächlich hat sich bei mir die Geschwindigkeit von Quicklook dramatisch verbessert, nachdem ich das Update auf 10.9.2 installiert habe.
Der lag ist weg.

Kann ich auch bestätigen. Bei mir geht's inzwischen auch wieder.