Dictionary lässt sich nicht als Datei speichern

  • Dictionary lässt sich nicht als Datei speichern

    Hab ein NSMutableDictionary in welches ich Bilder (NSImage) speichere.
    Nun lässt sich das Dict aber nicht auf die Platte speichern.

    Glaub ich hab es mir doch ne Spur zu einfach gemacht :-)
    Wie wäre es möglich es dennoch zu speichern?
    das ganze als NSData in das Dict schreiben und das speichern?

    Quellcode

    1. <CFDictionary 0x3c60c0 [0xa01900e0]>{type = mutable, count = 3, capacity = 4, pairs = (
    2. 0 : <CFString 0x5096380 [0xa01900e0]>{contents = "/Users/sven/Pictures/Wallpaper/muaa.jpg"} = NSImage 0x50604e0 Size={82, 65.6} Reps=(
    3. NSCachedImageRep 0x3af3d0 Size={82, 66} ColorSpace=NSCalibratedRGBColorSpace BPS=8 Pixels=82x66 Alpha=YES
    4. )
    5. .
    6. .
    7. .
    8. )}
    9. Coud not save Image-Cache to /Users/sven/Library/Application Support/CocoViewX/imagecache.plist


    Gruß Sven
    :wq! /dev/null

  • RE: Dictionary lässt sich nicht als Datei speichern

    Original von Stalkingwolf
    Glaub ich hab es mir doch ne Spur zu einfach gemacht :)

    jup
    Wie wäre es möglich es dennoch zu speichern?
    das ganze als NSData in das Dict schreiben und das speichern?

    genau so mach ich das im zweifel auch

  • Genauer kann man es so sagen:

    The NSPropertyListSerialization class provides methods that convert property list objects to and from several serialized formats. Property list objects include NSData, NSString, NSArray, NSDictionary, NSDate, and NSNumber objects.

    developer.apple.com/documentat…pertyListSerialztion.html

    Und NSImage ist kein Property list object.

    Gruss

    Alex
    The only thing that really worried me was the ether.

  • Schade, dachte er könnte es auch speichern, wenn er schon aufnehmen kann.

    Ok ich hab es nun über NSData gelöst.
    Wird natürlich relativ schnell groß die Datei.

    Es handelt sich um ca max. 128x128 Pixel Thumbnails als TIFF die in einem NSDictionary sind.
    3 Bilder belegen schon 215kb.
    Kann ich den Output vorher komprimieren und nachher wieder dekomprimieren?

    Sven
    :wq! /dev/null

  • Original von Stalkingwolf
    Es handelt sich um ca max. 128x128 Pixel Thumbnails als TIFF die in einem NSDictionary sind.
    3 Bilder belegen schon 215kb.
    Kann ich den Output vorher komprimieren und nachher wieder dekomprimieren?

    Sven

    Hallo Sven,

    TIFFs komprimieren ist ein Umweg, wieso nimmst Du nicht einfach Jpeg´s? Da kommst Du in die Gegend von 10-20kb.

    Gruss
    jerry

  • zu langsam.
    Ich zeichne die kleinen Bilder in einem Thread aus den Original Bildern und speichere die einmal in einem Array was zur Tabelle gehört und zusätzlich noch in einem Dictionary als Cache.
    Wenn ich diese nun jedesmal ins JPEG Format umwandel müsste.
    Vorallem hätte ich dann nur Bilder in einem Verzeichnis, so nur eine .plist Datei.

    Sven
    :wq! /dev/null

  • Hi,

    1. Musst du die Bilder wirklich zwischenspeichern? Wenn es um das zurückgeben der neuen Daten aus dem Thread geht, kannst du ja auch "zurückrufen" wenn du fertig bist und die Daten übergeben.

    2. Wenn du unbedingt cachen willst, würde ich die Daten nicht in das Property File legen. Plists werden jedesmal geparsed, "riesige" Datenobjekte können den Parser bestimmt schnell ausbremsen. Ich denke mal, wenn du ein Verzeichnis anlegst, in dem du deine Bilder speicherst und dazu ne "Datenbank" in Form einer plist pflegst gehts besser (stell dir mal vor iTunes würde die MP3 in seiner plist mitspeichern - bis ne plist mit 10GByte durchgeparsed ist ...)

    so long - Manfred
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Ich schreibe die Plist Datei nur beim beenden des Programmes weg und lade Sie beim starten wieder.
    Die Datei wird auf ca 1000 Objekte gehalten.
    Dictionaries sind Hashtabellen, was schnelleres werde ich wohl nicht hinbekommen.
    Habs mit 1000 Bildern getestete, super flott das ganze.

    Die frage ist nun wirklich wie ich das ganze am besten beim beenden auf die Platte speichere und beim starten wieder lade.

    Sven
    :wq! /dev/null

  • Original von Stalkingwolf
    zu langsam.

    Zu langsam? Ich habe ein 400 Mhz-G3 Powerbook und das schafft ca. 20 Bilder 14x21cm 300dpi als Jpeg gespeichert zu 256x256 Thums zu rechnen und zu speichern...

    Ich zeichne die kleinen Bilder in einem Thread aus den Original Bildern und speichere die einmal in einem Array was zur Tabelle gehört und zusätzlich noch in einem Dictionary als Cache.

    Warum Cache? Verstehe ich nicht.

    Wenn ich diese nun jedesmal ins JPEG Format umwandel müsste.
    Vorallem hätte ich dann nur Bilder in einem Verzeichnis, so nur eine .plist Datei.

    Dann liess Dir doch die Thumbs bei Bedarf ein. Das geht schnell. Als Verzeichnis bietet sich z.B. Application Support/MeinAppOrdner/ an.

    Gruss
    jerry

  • Wenn du unbedingt cachen willst, würde ich die Daten nicht in das Property File legen


    Richtig, Du könntest die Dinge auch ganz normal über NSCoder speichern. Evtl. ist NSImage schon coding compliant, sonst musst Du eine Subclass machen.

    Gruss

    Alex
    The only thing that really worried me was the ether.

  • Es geht um einen Dateibrowser mit Miniaturansicht.
    Da möchte ich die Bilder cachen, damit ich beim Ornder wechsel nicht immer die Bilder wieder neu generieren muss.
    Das wandeln ins JPG Format ist dafür viel zu langsam.

    Kollege brachte mich aber auf ne andere Idee.
    Thumbs immer gleich groß in eine Datei schreiben.
    Datei beim laden öffnen, darin mit fseek an die Stelle der Bilder springen und per fread lesen. Beim beenden des Programmes den Dateipointer wieder schließen.

    Zwar Auffwand, aber wohl die schnellste und beste Idee.
    Somit habe ich auch nicht die Dateien die ganze Zeit im Speicher.

    Sven
    :wq! /dev/null

  • JPG fällt noch wegen was anderem aus ... Keine Transparent.
    Daher kommt auch nur ein 128x128Pixel Bild 32Bit in Frage. 64KB pro Thumbnail .

    Damit stehen 2 Möglichkeiten zur Verfügung.
    1.) Die Lösung die ich oben geschrieben hatte per read write lseek
    2.) Tiff Bilder auf die Platte schreiben und diese bei Bedarf laden.

    Naja mal schauen was draus wird.

    Sven
    :wq! /dev/null

  • Kollege brachte mich aber auf ne andere Idee.
    Thumbs immer gleich groß in eine Datei schreiben.
    Datei beim laden öffnen, darin mit fseek an die Stelle der Bilder springen und per fread lesen. Beim beenden des Programmes den Dateipointer wieder schließen.

    Also ich behaupte mal, das es doch etwas einfacher ist alle "Thumbnails" in ein Verzeichnis zu speichern, ne "Datenbank" zu führen, die klein bleibt und ruck zuck bearbeitet werden kann und deine Images einfach bei Bedarf reinzuschreiben oder auszulesen - aber du bist ja groß ;) Warum willst du unbedingt mit einer Datei hantieren die schnell ganz groß wird und damit schwer zu handeln, ob ein Geschwindigkeitsvorteil den du damit erzielst das wirklich wert ist - falls der überhaupt noch da ist, bis du einen inkrementellen Zugriff implementiert hast?

    Wenn ich das richtig verstanden habe, gehts um nen Browser der dir dann z.B. wenn du in einem Verzeichnis bist eine Vorschau darstellt. Ich glaube da kommen sehr schnell riesige Datenmengen zusammen, die du gerne direkt im Speicher hättest wegen der Geschwindigkeit - oder?

    Wird das nicht ganz schnell ne riesige Datenhalde?
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • wenn ich mittel open eine Datei öffne und darin mit lseek an die Position springe und mit read einen ganzen Block lese, bin ich um einges schneller wie wenn ich jedesmal mit NSImage wieder eine DAtei von der Platte lade.

    Mein Anfangsweg war komplett verkehrt. Ein Dictionary im Speicher zu halten schreibt nur den Speicher voll.
    Ich werde einmal beide Methoden integrieren und dann schauen was schneller ist.


    Sven
    :wq! /dev/null