CGBitmapContextCreate: unsupported parameter combination - macos

I'm getting this error when creating a bitmap context:
CGBitmapContextCreate: unsupported parameter combination: 8 integer bits/component; 24 bits/pixel; 3-component color space; kCGImageAlphaNone; 7936 bytes/row.
Here's the code (note that the context is based on the parameters of an existing CGImage:
context = CGBitmapContextCreate(NULL,
(int)pi.bufferSizeRequired.width,
(int)pi.bufferSizeRequired.height,
CGImageGetBitsPerComponent(imageRef),
0,
CGImageGetColorSpace(imageRef),
CGImageGetBitmapInfo(imageRef));
Width is 2626, height is 3981. I've leaving bytesPerRow at zero so that it gets calculated automatically for me, and it's chosen 7936 of its own accord.
So, where on Earth is the inconsistency? It's driving me nuts.

For reasons that I don't understand I solved this by setting the BitmapInfo parameter to kCGImageAlphaNoneSkipLast.

CGBitmapContextCreate: unsupported parameter combination: 8 integer bits/component; 24 bits/pixel; 3-component color space; kCGImageAlphaNone; 7936 bytes/row.
In the Quartz 2D Programming documentation is a list of the supported pixel formats. The 8/3/24 combination is not supported but 8/3/32 is, independent of using alpha or not.

Heinrich gave you a good background to the answer. Just thought I'd offer up my specific case, as an alternative to tarmes' answer. The problem with that answer is that it doesn't solve the issue if you want an alpha channel present. I was using a category called UIImage+Alpha by Trevor Harmon when I encountered this issue. In the code I found this comment:
// The bitsPerComponent and bitmapInfo values are hard-coded to prevent an "unsupported parameter combination" error
Now this hardcoded fix was in one of the methods calling CGBitmapContextCreate, but not the one following it. So for me it was simply a matter of following the author's own advice to fix the problem in one of his other methods ;)
Clearly some part of the CGBitmapInfo is not getting passed correctly from the image in question, though why I don't know.
So use these constants in the bitmapInfo if you're working with the alpha channel: kCGBitmapByteOrderDefault | kCGImageAlphaPremultipliedFirst
Otherwise, I'd just like to point out it's a really useful class if you're dealing with aliasing issues!
(Also, worth mentioning this problem only turned up in Xcode 6....)

I'm not sure it would help anybody or not, I just run into the similar issue and try anyway as suggested but no luck.
My issue is:
CCLabelTTF *header_txt = [CCLabelTTF
labelWithString:header
fontName:fontname fontSize:header_fontsize
dimensions:CGSizeMake(header_fontsize*9, txt_h)
hAlignment:kCCTextAlignmentLeft
vAlignment:kCCVerticalTextAlignmentCenter];
With Error:
< Error >: CGBitmapContextCreate: unsupported parameter combination: 8 integer bits/component; 8 bits/pixel; 1-component color space; kCGImageAlphaNone; 2147483648 bytes/row.
Then I found a mistake is that header_fontsize is not assigned any values (because I mistake fontsize with header_fontsize). The error lies here: dimensions:CGSizeMake(header_fontsize*9, txt_h) with header_fontsize unassigned any value (it's not 0, assign header_fontsize = 0still ok); reassign a value to header_fontsize fixed the issue.
Hope this will help someone in similar case, such as Sprite case.

Some pixel formats are just unsupported.
You can check in advance if any image is supported with:
extension CGImage {
public var hasCGContextSupportedPixelFormat: Bool {
guard let colorSpace = self.colorSpace else {
return false
}
#if os(iOS) || os(watchOS) || os(tvOS)
let iOS = true
#else
let iOS = false
#endif
#if os(OSX)
let macOS = true
#else
let macOS = false
#endif
switch (colorSpace.model, bitsPerPixel, bitsPerComponent, alphaInfo, bitmapInfo.contains(.floatComponents)) {
case (.unknown, 8, 8, .alphaOnly, _):
return macOS || iOS
case (.monochrome, 8, 8, .none, _):
return macOS || iOS
case (.monochrome, 8, 8, .alphaOnly, _):
return macOS || iOS
case (.monochrome, 16, 16, .none, _):
return macOS
case (.monochrome, 32, 32, .none, true):
return macOS
case (.rgb, 16, 5, .noneSkipFirst, _):
return macOS || iOS
case (.rgb, 32, 8, .noneSkipFirst, _):
return macOS || iOS
case (.rgb, 32, 8, .noneSkipLast, _):
return macOS || iOS
case (.rgb, 32, 8, .premultipliedFirst, _):
return macOS || iOS
case (.rgb, 32, 8, .premultipliedLast, _):
return macOS || iOS
case (.rgb, 64, 16, .premultipliedLast, _):
return macOS
case (.rgb, 64, 16, .noneSkipLast, _):
return macOS
case (.rgb, 128, 32, .noneSkipLast, true):
return macOS
case (.rgb, 128, 32, .premultipliedLast, true):
return macOS
case (.cmyk, 32, 8, .none, _):
return macOS
case (.cmyk, 64, 16, .none, _):
return macOS
case (.cmyk, 128, 32, .none, true):
return macOS
default:
return false
}
}
}
See https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_context/dq_context.html for more information (and the list of supported pixel formats)

Related

How do I get this XWindows.XGetImage call right?

(update: the XGetPixel problem has been solved thanks to David)
I am practicing some tasks from rosettacode.org for Standard ML, and I am stuck with the XGetImage call from XWindows (PolyML) . I get a badValue error for every attempt in XYPixmap format.
What I did, was
open XWindows ;
val disp = XOpenDisplay "" ;
val win = XCreateSimpleWindow (RootWindow disp) origin (Area {x=0,y=0,w=300,h=100}) 2 0 0xffffff ;
XMapWindow win;
XFlush disp ;
XGetImage win (Area {x=0,y=0,w=100,h=100}) AllPlanes XYPixmap ;
The XGetImage call returns
X Error BadValue in XGetImage
Exception- XWindows "XGetImage failed" raised
The xwindows.cpp source does not make me much wiser:
XImage *image = XGetImage(d,drawable,x,y,w,h,mask,CImageFormat(format));
if (image == 0) RaiseXWindows(taskData, "XGetImage failed");
ZPixmap + XGetPixel work fine in the most recent polyversion, the rest of this post has been solved:
When I try ZPixmap, i get
val im = XGetImage win (Area {x=0,y=0,w=1,h=1}) AllPlanes ZPixmap ;
val im =
XImage
{bitmapBitOrder = MSBFirst, bitmapPad = 32, bitmapUnit = 32,
bitsPerPixel = 1, byteOrder = MSBFirst, bytesPerLine = 4, data =
ImageData
"\^A\^#\^#\^# ... repeat 22 x .... \^A\^#\^#\^#",
depth = 24, format = ZPixmap, size =
Rect {bottom = 1, left = 0, right = 1, top = 0}, ...}
but
XGetPixel disp im (XPoint {x=0,y=0}) ;
crashes PolyML
The XGetImage example (in C) in the Xlib Programming Manual chapter 6.4.2 does not seem to do anything special, just use the display and a visible window. My window win is visible. I also tried the root window, and that does not work either. I think I have followed the PolyML for X manual correctly.
What is missing here ?
It seems there was a bug in the code that implemented XGetPixel in Poly/ML. There is a fix for that now in the github repository. I'm not familiar enough with X-windows to be able to say whether it should work with XYPixmap.

How to detect screen resize events coming from ncurses in QNX?

I can not configure to receive events about changing the size of the terminal using ncurses QNX Momentics.
I am using Putyy as a terminal and data is transmitted through the COM port.
My question is how to realize the reception of screen change events when using a remote terminal?
FILE* fcons = fopen("/dev/ser1", "r+");
SCREEN* term = newterm("xterm-r5", fcons, fcons);
int y = 0, x = 0;
//if(y < 24 || x < 80)
// resizeterm(24, 80);
flushinp();
main_scr = newwin(24, 80, 0, 0);
head_scr = subwin(main_scr, 3, 80, 0, 0);
prompt_scr = subwin(main_scr, 1, 9, 3, 2);
cursor_scr = newwin(1, 60, 3, 6);
output_scr = subwin(main_scr, 18, 76, 5, 2);
keypad(cursor_scr, TRUE);
int f = mousemask(ALL_MOUSE_EVENTS, NULL);
chtype temp_ch = 0;
while(KEY_RESIZE == temp_ch)
temp_ch = wgetch(cursor_scr);
return 0;
A plain serial-port connection like that won't send a SIGWINCH. In other configurations, e.g., telnet, that's done as a result of NAWS (negotiations about window size--I dont't see a duplicate). Your application could poll for this by doing what the resize program does, plus a little more, e.g.,
save the cursor-position
move the cursor to a very-far-off lower-right corner
ask the terminal where the cursor really is
wait for the response, to get the actual screensize
set the terminal's screensize using a system call
restore the cursor position
send a SIGWINCH to yourself
Unlike resize, that would be done inside your program, so it would have to save/restore the cursor position (to avoid confusing ncurses). Keep in mind that ncurses has set the terminal to raw mode, so that part of the initialization would not be needed.

Swift 3 type inference error in Xcode 8.2.1, in swift-style for statement

I don't know if anybody else has met this problem. I updated my Xcode to 8.2.1 today. When I tried to place several buttons on a scrollView, I found a type inference error. The core code is shown below:
for i in 0 ..< 6 {
let titleButton = UIButton(frame: CGRect(x: CGFloat(i) * titleWidth, y: 0, width: titleWidth, height: titleHeight))
sv.addSubview(titleButton)
}
The code had no problem to place 6 buttons on the scrollView(sv), but when I tried to set a title for each button Using call:setTitle(_ title: String?, for state: UIControlState) under the initialization of the button, Xcode did not show method completion suggest. I found the reason is 'titleButton' is inferred as error type by Xcode.
Then I tried:
for i in 0 ..< 6 {
let frame = CGRect(x: CGFloat(i) * titleWidth, y: 0, width: titleWidth, height: titleHeight)
let titleButton = UIButton(frame: frame)
sv.addSubview(titleButton)
}
And found 'frame' is inferred as error type, so the type inference failure of 'titleButton' seems from the frame. Finally I found that the variable 'i' from the beginning of this for statement is inferred as error type, that is the origin.
I didn't find similar problem in past Xcode versions. If I really need to use 'i' in my logic among for-loop, is there someone who has an idea to solve the inference error?
To fix this, I have to indicate the type myself as follow:
let titleButton : UIButton = UIButton(frame: frame)
Then under this, the method completion suggestion works fine. Hope Apple can fix the type inference error quickly...

Error: Use of unresolved identifier 'kCGBlendModeMultiply'

I recently updated to Xcode 7, beta 3.
And I've run into some issues, I can't seem to find any questions for on SO.
When I run my application, i get 3 errors:
Use of unresolved identifier 'kCGBlendModeMultiply'
Use of unresolved identifier 'kCGLineCapRound'
Use of unresolved identifier 'kCGLineJoinMiter'
However the 2 latter ones, disappear, although I assume they will show up after the first one is fixed (hence why I included it in this question).
I didn't see anything in the release notes about these being removed? So I'm a bit stuck at what to do. I tried rewriting the lines of course, but the 3 things I used don't show up as options anymore. In case that they are just gone in the latest Swift 2.0, what can I use instead?
Here's the code for the first error.
func alpha(value:CGFloat)->UIImage
{
UIGraphicsBeginImageContextWithOptions(self.size, false, 0.0)
let ctx = UIGraphicsGetCurrentContext()
let area = CGRect(x: 0, y: 0, width: self.size.width, height: self.size.height)
CGContextScaleCTM(ctx, 1, -1);
CGContextTranslateCTM(ctx, 0, -area.size.height)
CGContextSetBlendMode(ctx, kCGBlendModeMultiply)
CGContextSetAlpha(ctx, value)
CGContextDrawImage(ctx, area, self.CGImage)
let newImage = UIGraphicsGetImageFromCurrentImageContext()
UIGraphicsEndImageContext()
return newImage;
}
Here's the code for the 2 latter errors:
for layer in [ self.top, self.middle, self.bottom ] {
layer.fillColor = nil
layer.strokeColor = UIColor.whiteColor().CGColor
layer.lineWidth = 4
layer.miterLimit = 4
layer.lineCap = kCALineCapRound
layer.masksToBounds = true
let strokingPath = CGPathCreateCopyByStrokingPath(layer.path, nil, 4, kCGLineCapRound, kCGLineJoinMiter, 4)
layer.bounds = CGPathGetPathBoundingBox(strokingPath)
layer.actions = [
"strokeStart": NSNull(),
"strokeEnd": NSNull(),
"transform": NSNull()
]
self.layer.addSublayer(layer)
}
Any help would be greatly appreciated! :)
This should work:
CGContextSetBlendMode(ctx, CGBlendMode.Multiply)
... or even just this:
CGContextSetBlendMode(ctx, .Multiply)
If you Ctrl-click on CGContextSetBlendMode and then from its declaration jump (in the same way) to declaration of CGBlendMode then you will see:
enum CGBlendMode : Int32 {
/* Available in Mac OS X 10.4 & later. */
case Normal
case Multiply
case Screen
case Overlay
// ...
}
Similarly, the other line that produces the error should be changed to:
let strokingPath = CGPathCreateCopyByStrokingPath(layer.path, nil, 4, .Round, .Miter, 4)

NSPopUpButton with InlineButton style logs "Unknown bezel style 15 and/or control size 1"

I have an NSPopUpButton with Inline Button style.
When mouse enters, exits or mouse down or mouse up, it logs "Unknown bezel style 15 and/or control size 1"
15 is the NSInlineButtonStyle from NSButtonCell.h
typedef NS_ENUM(NSUInteger, NSBezelStyle) {
NSRoundedBezelStyle = 1,
NSRegularSquareBezelStyle = 2,
NSThickSquareBezelStyle = 3,
NSThickerSquareBezelStyle = 4,
NSDisclosureBezelStyle = 5,
NSShadowlessSquareBezelStyle = 6,
NSCircularBezelStyle = 7,
NSTexturedSquareBezelStyle = 8,
NSHelpButtonBezelStyle = 9,
NSSmallSquareBezelStyle = 10,
NSTexturedRoundedBezelStyle = 11,
NSRoundRectBezelStyle = 12,
NSRecessedBezelStyle = 13,
NSRoundedDisclosureBezelStyle = 14,
// The inline bezel style contains a solid round-rect border background. It can be used to create an "unread" indicator in an outline view, or another inline button in a tableview, such as a stop progress button in a download panel. Use text for an unread indicator, and a template image for other buttons.
NSInlineBezelStyle NS_ENUM_AVAILABLE_MAC(10_7) = 15,
NSSmallIconButtonBezelStyle NS_ENUM_DEPRECATED_MAC(10_0, 10_0) = 2 // This bezel style is obsolete and should not be used.
};
Oddly, everything compiles fine, and I set the style in Interface Builder.
Everything also works fine except for this console spew.
I was unable to find anything in the docs or the headers for NSButton, NSPopUpButton, NSButtonCell, NSPopUpButtonCell, NSMenuItemCell that warn or prohibit this style.
And the size is set by constraints with no auto layout issues logged.
The spew to the console does not contain any indicator of where this message comes from. I can only tell by observed behavior.
Unknown bezel style 15 and/or control size 1
Is there a way to silence this?
Currently it seems to be a bug.

Resources