CGRect Größe wirkt sich nicht auf die Größe der NSBitmapImageRep aus

Tobias Scholze

Apfeltalk Entwicker
AT Redaktion
Mitglied seit
15.07.09
Beiträge
1.581
Hi ihr,

ich möchte auf dem Mac ein Bild in der Größe manipulieren und anschließend dieses als neues Bild auf die Platte schreiben.
Generell funktioniert es auch. Allerdings wird die veränderte Größe des CGRect in der NSBitmapImageRep nicht beachtet und das Bild wird in der gleichen Größe erstellt welche das Originalbild hat. Gewünscht ist als Beispiel eine Breite und Höhe von jeweils 50 Pixeln.

Anmerkung
  • Image entspricht dem Originalbild
  • Swift 2.x

Quelltext
Code:
        var recRef: CGRect = CGRectMake(0, 0, 50, 50)
        let imageRef = image!.CGImageForProposedRect(&recRef, context: nil, hints: nil)
        let data = NSBitmapImageRep(CGImage: imageRef!).representationUsingType(.NSPNGFileType, properties: [:])!
        data.writeToFile(NSString(string: "~/Documents/resizedImage.png").stringByExpandingTildeInPath, atomically: true)
Siehe auch
 

Marcel Bresink

Nathusius Taubenapfel
Mitglied seit
28.05.04
Beiträge
5.491
Ich werde jetzt kein fertiges Programm angeben, schon gar nicht in Swift, aber der grundsätzliche Denkfehler ist, dass Du annimmst, die Koordinaten wären in Pixel angegeben.

Das Koordinatensystem hat immer die Einheit Point, nicht Pixel. Du gibst also dem NSImage nur die Anweisung, dass es sich jetzt als Bild der Größe 50/72 Zoll, also etwa 18mm x 18mm verstehen soll. Da kein Kontext gegeben war und damit keine physische Auflösung, die sagen würde, wie groß konkret ein Pixel ist, brauchte das Bild nicht neu gerendert zu werden. Wenn sich an dem Bild überhaupt etwas ändert, dann nur die Metadaten der physischen Größe.

Eine der möglichen Lösungen für diese Fragestellung ist,

ein NSBitmapImageRep mit den gewünschten Parametern von Hand anzulegen (über init?(bitmapDataPlanes planes, pixelsWide width, pixelsHigh height, bitsPerSample bps, samplesPerPixel spp, hasAlpha alpha, isPlanar isPlanar, colorSpaceName colorSpaceName, bitmapFormat bitmapFormat, bytesPerRow rBytes, bitsPerPixel pBits)),

dann einen NSGraphicsContext zu erzeugen, der diese Bitmap zum Ziel hat (graphicsContextWithBitmapImageRep),
und dann das Eingangs-Image zu zwingen, sich in diesen Kontext hineinzuzeichnen.
 

Tobias Scholze

Apfeltalk Entwicker
AT Redaktion
Mitglied seit
15.07.09
Beiträge
1.581
Vielen Danke @Marcel Bresink.
Irgendwie hab ich das Gefühl, dass Swift unter OS X stiefmütterlich behandelt wird. :/

VLG, Tobi
 

Tobias Scholze

Apfeltalk Entwicker
AT Redaktion
Mitglied seit
15.07.09
Beiträge
1.581
Jein. Unter iOS hast du *geschicktere* Methoden welche einen Zwischenschritt selbst abhandeln. Dies würde natürlich nichts an meinem Fehler mit dem Koordinatensystem ändern.

Was jedoch wäre. Man soll / will das Rat ja nicht neu erfinden. Darum hätte ich auf CocoaPods gesetzt - leider gibt es für diesen Fall keine für OS X.

VLG, Tobi
 

MacApple

Schmalzprinz
Mitglied seit
05.01.04
Beiträge
3.587
Jein. Unter iOS hast du *geschicktere* Methoden welche einen Zwischenschritt selbst abhandeln. Dies würde natürlich nichts an meinem Fehler mit dem Koordinatensystem ändern.
Eben, mit Swift hat das nichts zu tun. Der Compiler ist für beide Systeme der selbe.

Was jedoch wäre. Man soll / will das Rat ja nicht neu erfinden. Darum hätte ich auf CocoaPods gesetzt - leider gibt es für diesen Fall keine für OS X.
Und CocoaPods hat noch nicht mal was mit Apple zu tun.
 

Tobias Scholze

Apfeltalk Entwicker
AT Redaktion
Mitglied seit
15.07.09
Beiträge
1.581
Hi,
nicht ganz. Unter iOS hast du die UIImagePNGRepresentation Methode. Diese würde auf den ersten Blick den Workflow vereinfachen. Aber schmu ist schmu. Es geht einfach anders und irgendwie entwickelt nur noch der kleinere Teil der Entwickler für den Mac.

VLG, Tobi
 

Marcel Bresink

Nathusius Taubenapfel
Mitglied seit
28.05.04
Beiträge
5.491
Unter iOS hast du die UIImagePNGRepresentation Methode.
Das liegt daran, dass UIImage quasi eine eingeschränkte Version von NSImage ist (nur Bitmaps, keine Vektorgrafik wie z.B. PDF), um dem Rechnung zu tragen, dass die Beschränkung auf Bitmaps auf Mobilgeräten stromsparender und deshalb angemessener ist. Wenn man weniger Funktionen bereitstellt, sieht es auf den ersten Blick einfacher aus. Aber eigentlich entspricht UIImagePNGRepresentation() dem oben schon erwähnten "representationUsingType(.NSPNGFileType...)".

Wie MacApple kann ich nicht ganz folgen, was diese Behauptungen mit der Fragestellung zu tun haben sollen.