Mixing
CVMetalTextureCacheCreateTextureFromImage - pixelFormat
From the tests I did, the pixelFormat parameter of CVMetalTextureCacheCreateTextureFromImage is the pixel format of the metal texture and not the actual pixel format of data in the Cove Video buffer. Is this right?
In that case, where and when the conversion is done (if the texture and buffer formats are different)? Is there any performance penallity for that conversion?
EDIT:
I rechecked documentation and the pixelFormat parameter is described as follow: "The Metal pixel format constant describing the image buffer’s "data. So the pixelFormat should match the pixel format of the Core Video buffer data, no?
However, for the same Core Video buffer (whichcontains integer data), it works if I use either MTLPixelFormatR8Uint or MTLPixelFormatR8Unorm. The only difference is that the values received in my shader are either integers [0..255] or floats [0.0..1.0]. In the later case, I would have expected to receive garbage since the intergers is the buffer would have been interpreted as floats. No?
ios textures metal
asked Nov 21 '18 at 18:01
YoshiYoshi
618
|
show 3 more comments
From the tests I did, the pixelFormat parameter of CVMetalTextureCacheCreateTextureFromImage is the pixel format of the metal texture and not the actual pixel format of data in the Cove Video buffer. Is this right?
In that case, where and when the conversion is done (if the texture and buffer formats are different)? Is there any performance penallity for that conversion?
EDIT:
I rechecked documentation and the pixelFormat parameter is described as follow: "The Metal pixel format constant describing the image buffer’s "data. So the pixelFormat should match the pixel format of the Core Video buffer data, no?
However, for the same Core Video buffer (whichcontains integer data), it works if I use either MTLPixelFormatR8Uint or MTLPixelFormatR8Unorm. The only difference is that the values received in my shader are either integers [0..255] or floats [0.0..1.0]. In the later case, I would have expected to receive garbage since the intergers is the buffer would have been interpreted as floats. No?
ios textures metal
asked Nov 21 '18 at 18:01
YoshiYoshi
618
MTLPixelFormatR8Unorminterprets the data as unsigned integers and then converts them to floats in the range [0.0..1.0]. It does not expect the data to already be some 8-bit floating-point type.
– Ken Thomases
Nov 21 '18 at 19:16
So pixelFormat is not the format of the Core Video buffer data as described by the documentation, right? Also, Is there any performance penalty for that conversion? From what I recall, conversion from integer to float are free when done in the shader.
– Yoshi
Nov 21 '18 at 20:40
It is the format of the Core Video buffer data. What did I say that implied otherwise? BothMTLPixelFormatR8UintandMTLPixelFormatR8Unormsay that the buffer data consists of 8-bit unsigned integers in the range from [0..255]. It's just that, in shaders, unsigned normalized values are presented as floating-point values. That doesn't affect what's in the buffer data. I don't know for sure about a performance penalty, but 8-bitUnormformats are very common for rendering, so they're presumably plenty fast.
– Ken Thomases
Nov 21 '18 at 22:27
If the difference between MTLPixelFormatR8Uint and MTLPixelFormatR8Unorm is not the buffer data type (both say that the buffer data consists of 8-bit unsigned integers in the range from [0..255]) but rather how the MTLTexture outputs its values, isn't correct to says that the pixelFormat parameter describe the pixel format (or the output) of the MTLTexture?
– Yoshi
Nov 21 '18 at 23:33
Ok, I think I got it... both those format doesn't says how The MTLTexture should output its values but they rather says how the 8-bit interger values in the buffer should be interpreted (i.e. their format).. For Uint, it mean that 255 is 255 and for Unorm, 255 mean max range and thus 1.0. I got it?
– Yoshi
Nov 22 '18 at 0:09
|
show 3 more comments
From the tests I did, the pixelFormat parameter of CVMetalTextureCacheCreateTextureFromImage is the pixel format of the metal texture and not the actual pixel format of data in the Cove Video buffer. Is this right?
In that case, where and when the conversion is done (if the texture and buffer formats are different)? Is there any performance penallity for that conversion?
EDIT:
I rechecked documentation and the pixelFormat parameter is described as follow: "The Metal pixel format constant describing the image buffer’s "data. So the pixelFormat should match the pixel format of the Core Video buffer data, no?
However, for the same Core Video buffer (whichcontains integer data), it works if I use either MTLPixelFormatR8Uint or MTLPixelFormatR8Unorm. The only difference is that the values received in my shader are either integers [0..255] or floats [0.0..1.0]. In the later case, I would have expected to receive garbage since the intergers is the buffer would have been interpreted as floats. No?
ios textures metal
asked Nov 21 '18 at 18:01
YoshiYoshi
618
From the tests I did, the pixelFormat parameter of CVMetalTextureCacheCreateTextureFromImage is the pixel format of the metal texture and not the actual pixel format of data in the Cove Video buffer. Is this right?
In that case, where and when the conversion is done (if the texture and buffer formats are different)? Is there any performance penallity for that conversion?
EDIT:
I rechecked documentation and the pixelFormat parameter is described as follow: "The Metal pixel format constant describing the image buffer’s "data. So the pixelFormat should match the pixel format of the Core Video buffer data, no?
However, for the same Core Video buffer (whichcontains integer data), it works if I use either MTLPixelFormatR8Uint or MTLPixelFormatR8Unorm. The only difference is that the values received in my shader are either integers [0..255] or floats [0.0..1.0]. In the later case, I would have expected to receive garbage since the intergers is the buffer would have been interpreted as floats. No?
ios textures metal
ios textures metal
asked Nov 21 '18 at 18:01
YoshiYoshi
618
asked Nov 21 '18 at 18:01
YoshiYoshi
618
asked Nov 21 '18 at 18:01
YoshiYoshi
618
asked Nov 21 '18 at 18:01
YoshiYoshi
618
asked Nov 21 '18 at 18:01
YoshiYoshi
618
618
MTLPixelFormatR8Unorminterprets the data as unsigned integers and then converts them to floats in the range [0.0..1.0]. It does not expect the data to already be some 8-bit floating-point type.
– Ken Thomases
Nov 21 '18 at 19:16
So pixelFormat is not the format of the Core Video buffer data as described by the documentation, right? Also, Is there any performance penalty for that conversion? From what I recall, conversion from integer to float are free when done in the shader.
– Yoshi
Nov 21 '18 at 20:40
It is the format of the Core Video buffer data. What did I say that implied otherwise? BothMTLPixelFormatR8UintandMTLPixelFormatR8Unormsay that the buffer data consists of 8-bit unsigned integers in the range from [0..255]. It's just that, in shaders, unsigned normalized values are presented as floating-point values. That doesn't affect what's in the buffer data. I don't know for sure about a performance penalty, but 8-bitUnormformats are very common for rendering, so they're presumably plenty fast.
– Ken Thomases
Nov 21 '18 at 22:27
If the difference between MTLPixelFormatR8Uint and MTLPixelFormatR8Unorm is not the buffer data type (both say that the buffer data consists of 8-bit unsigned integers in the range from [0..255]) but rather how the MTLTexture outputs its values, isn't correct to says that the pixelFormat parameter describe the pixel format (or the output) of the MTLTexture?
– Yoshi
Nov 21 '18 at 23:33
Ok, I think I got it... both those format doesn't says how The MTLTexture should output its values but they rather says how the 8-bit interger values in the buffer should be interpreted (i.e. their format).. For Uint, it mean that 255 is 255 and for Unorm, 255 mean max range and thus 1.0. I got it?
– Yoshi
Nov 22 '18 at 0:09
|
show 3 more comments
MTLPixelFormatR8Unorminterprets the data as unsigned integers and then converts them to floats in the range [0.0..1.0]. It does not expect the data to already be some 8-bit floating-point type.
– Ken Thomases
Nov 21 '18 at 19:16
So pixelFormat is not the format of the Core Video buffer data as described by the documentation, right? Also, Is there any performance penalty for that conversion? From what I recall, conversion from integer to float are free when done in the shader.
– Yoshi
Nov 21 '18 at 20:40
It is the format of the Core Video buffer data. What did I say that implied otherwise? BothMTLPixelFormatR8UintandMTLPixelFormatR8Unormsay that the buffer data consists of 8-bit unsigned integers in the range from [0..255]. It's just that, in shaders, unsigned normalized values are presented as floating-point values. That doesn't affect what's in the buffer data. I don't know for sure about a performance penalty, but 8-bitUnormformats are very common for rendering, so they're presumably plenty fast.
– Ken Thomases
Nov 21 '18 at 22:27
If the difference between MTLPixelFormatR8Uint and MTLPixelFormatR8Unorm is not the buffer data type (both say that the buffer data consists of 8-bit unsigned integers in the range from [0..255]) but rather how the MTLTexture outputs its values, isn't correct to says that the pixelFormat parameter describe the pixel format (or the output) of the MTLTexture?
– Yoshi
Nov 21 '18 at 23:33
Ok, I think I got it... both those format doesn't says how The MTLTexture should output its values but they rather says how the 8-bit interger values in the buffer should be interpreted (i.e. their format).. For Uint, it mean that 255 is 255 and for Unorm, 255 mean max range and thus 1.0. I got it?
– Yoshi
Nov 22 '18 at 0:09
MTLPixelFormatR8Unorm interprets the data as unsigned integers and then converts them to floats in the range [0.0..1.0]. It does not expect the data to already be some 8-bit floating-point type.– Ken Thomases
Nov 21 '18 at 19:16
MTLPixelFormatR8Unorm interprets the data as unsigned integers and then converts them to floats in the range [0.0..1.0]. It does not expect the data to already be some 8-bit floating-point type.– Ken Thomases
Nov 21 '18 at 19:16
So pixelFormat is not the format of the Core Video buffer data as described by the documentation, right? Also, Is there any performance penalty for that conversion? From what I recall, conversion from integer to float are free when done in the shader.
– Yoshi
Nov 21 '18 at 20:40
So pixelFormat is not the format of the Core Video buffer data as described by the documentation, right? Also, Is there any performance penalty for that conversion? From what I recall, conversion from integer to float are free when done in the shader.
– Yoshi
Nov 21 '18 at 20:40
It is the format of the Core Video buffer data. What did I say that implied otherwise? Both
MTLPixelFormatR8Uint and MTLPixelFormatR8Unorm say that the buffer data consists of 8-bit unsigned integers in the range from [0..255]. It's just that, in shaders, unsigned normalized values are presented as floating-point values. That doesn't affect what's in the buffer data. I don't know for sure about a performance penalty, but 8-bit Unorm formats are very common for rendering, so they're presumably plenty fast.– Ken Thomases
Nov 21 '18 at 22:27
It is the format of the Core Video buffer data. What did I say that implied otherwise? Both
MTLPixelFormatR8Uint and MTLPixelFormatR8Unorm say that the buffer data consists of 8-bit unsigned integers in the range from [0..255]. It's just that, in shaders, unsigned normalized values are presented as floating-point values. That doesn't affect what's in the buffer data. I don't know for sure about a performance penalty, but 8-bit Unorm formats are very common for rendering, so they're presumably plenty fast.– Ken Thomases
Nov 21 '18 at 22:27
If the difference between MTLPixelFormatR8Uint and MTLPixelFormatR8Unorm is not the buffer data type (both say that the buffer data consists of 8-bit unsigned integers in the range from [0..255]) but rather how the MTLTexture outputs its values, isn't correct to says that the pixelFormat parameter describe the pixel format (or the output) of the MTLTexture?
– Yoshi
Nov 21 '18 at 23:33
If the difference between MTLPixelFormatR8Uint and MTLPixelFormatR8Unorm is not the buffer data type (both say that the buffer data consists of 8-bit unsigned integers in the range from [0..255]) but rather how the MTLTexture outputs its values, isn't correct to says that the pixelFormat parameter describe the pixel format (or the output) of the MTLTexture?
– Yoshi
Nov 21 '18 at 23:33
Ok, I think I got it... both those format doesn't says how The MTLTexture should output its values but they rather says how the 8-bit interger values in the buffer should be interpreted (i.e. their format).. For Uint, it mean that 255 is 255 and for Unorm, 255 mean max range and thus 1.0. I got it?
– Yoshi
Nov 22 '18 at 0:09
Ok, I think I got it... both those format doesn't says how The MTLTexture should output its values but they rather says how the 8-bit interger values in the buffer should be interpreted (i.e. their format).. For Uint, it mean that 255 is 255 and for Unorm, 255 mean max range and thus 1.0. I got it?
– Yoshi
Nov 22 '18 at 0:09
|
show 3 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418065%2fcvmetaltexturecachecreatetexturefromimage-pixelformat%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418065%2fcvmetaltexturecachecreatetexturefromimage-pixelformat%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
MTLPixelFormatR8Unorminterprets the data as unsigned integers and then converts them to floats in the range [0.0..1.0]. It does not expect the data to already be some 8-bit floating-point type.– Ken Thomases
Nov 21 '18 at 19:16
So pixelFormat is not the format of the Core Video buffer data as described by the documentation, right? Also, Is there any performance penalty for that conversion? From what I recall, conversion from integer to float are free when done in the shader.
– Yoshi
Nov 21 '18 at 20:40
It is the format of the Core Video buffer data. What did I say that implied otherwise? Both
MTLPixelFormatR8UintandMTLPixelFormatR8Unormsay that the buffer data consists of 8-bit unsigned integers in the range from [0..255]. It's just that, in shaders, unsigned normalized values are presented as floating-point values. That doesn't affect what's in the buffer data. I don't know for sure about a performance penalty, but 8-bitUnormformats are very common for rendering, so they're presumably plenty fast.– Ken Thomases
Nov 21 '18 at 22:27
If the difference between MTLPixelFormatR8Uint and MTLPixelFormatR8Unorm is not the buffer data type (both say that the buffer data consists of 8-bit unsigned integers in the range from [0..255]) but rather how the MTLTexture outputs its values, isn't correct to says that the pixelFormat parameter describe the pixel format (or the output) of the MTLTexture?
– Yoshi
Nov 21 '18 at 23:33
Ok, I think I got it... both those format doesn't says how The MTLTexture should output its values but they rather says how the 8-bit interger values in the buffer should be interpreted (i.e. their format).. For Uint, it mean that 255 is 255 and for Unorm, 255 mean max range and thus 1.0. I got it?
– Yoshi
Nov 22 '18 at 0:09