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

[Tobias Scholze]

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

        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

• Original Stackoverflow Post

 

[Marcel Bresink]

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]

Vielen Danke @Marcel Bresink.
Irgendwie hab ich das Gefühl, dass Swift unter OS X stiefmütterlich behandelt wird. :/

VLG, Tobi

 

[MacApple]

Irgendwie hab ich das Gefühl, dass Swift unter OS X stiefmütterlich behandelt wird.

Warum? Dein Problem hat ist ja kein Swift-Problem. Ob du die Methoden per Swift oder Objective-C aufrufst, ändert nichts an der Funktionsweise der Methoden.

 

[Tobias Scholze]

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]

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.

 

[Marcel Bresink]

Unter iOS hast du *geschicktere* Methoden welche einen Zwischenschritt selbst abhandeln.

Äh, wie? Bei solchen Basisfunktionen gibt es keine Unterschiede. Stark vereinfacht gesagt hast Du bei iOS "keine Fenster, aber mehr Touch", aber der Rest ist gleich.

 

[Tobias Scholze]

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]

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.