-
Notifications
You must be signed in to change notification settings - Fork 104
Creating EncodedImage or EncodedDepthImage straight from memory stream? #178
As far I can tell, to create a new encoded image or depth image, I would need to provide a width and height. My application only receives the encoded byte stream + type ("png", "tiff", etc) but not the height or width. The height and width information are already encoded in the given byte stream.
This actually create a bit of problem when I am trying to decode the memory stream. I end up having to read it first to get the height and width and then convert it to a Psi format. Here's an example of how I work around it.
var decodedImg = new PngBitmapDecoder(imageMemoryStream, BitmapCreateOptions.PreservePixelFormat, BitmapCacheOption.Default);
BitmapSource bitmapSource = decodedImg.Frames[0];
using (var sharedDepthImage = DepthImagePool.GetOrCreate(bitmapSource.PixelWidth, bitmapSource.PixelHeight))
{
bitmapSource.CopyPixels(Int32Rect.Empty, sharedDepthImage.Resource.ImageData,
sharedDepthImage.Resource.Stride * sharedDepthImage.Resource.Height,
sharedDepthImage.Resource.Stride);
return sharedDepthImage.AddRef();
}
I'm guessing the height and width requirements exist to help with the shared<> ability. I also believe there is no way to save a memory stream into a pooled encoded depth image.
I think I'm looking for an easier way to:
- Given a stream of data consist of an encoded image, convert it into either
shared<EncodedDepthImage>orshared<EncodedImage> - Able to create
EncodedImageorEncodedDepthImagejust from a memorystream.
All reactions
Yes, you are correct that this is a current limitation of EncodedImage. The image dimensions need to be provided in the EncodedImage, and there currently isn’t a way to create one from just a memory stream. In the next release we'll be adding a SetBuffer method to provide the ability to set the underlying bytes, but you would still need to know the image dimensions up front when creating the EncodedImage. Unfortunately if your application doesn’t know the dimensions of the encoded byte streams it receives, then your current workaround is your best bet for now.
Replies: 1 comment 1 reply
Yes, you are correct that this is a current limitation of EncodedImage. The image dimensions need to be provided in the EncodedImage, and there currently isn’t a way to create one from just a memory stream. In the next release we'll be adding a SetBuffer method to provide the ability to set the underlying bytes, but you would still need to know the image dimensions up front when creating the EncodedImage. Unfortunately if your application doesn’t know the dimensions of the encoded byte streams it receives, then your current workaround is your best bet for now.
All reactions
-
👍 1
Thanks! This actually leads me into a potential request/suggestion about adding some functionalities to IImageFromStreamDecoder.cs and IDepthImageFromStreamDecoder.cs.
Right now, IImageFromStreamDecoder.cs already has a GetPixelFormat Method. Maybe we can extend this or add a new function that returns width and height?
/// <summary>
/// Gets the pixel format of an encoded image from a stream.
/// </summary>
/// <param name="stream">Stream containing the encoded image.</param>
/// <returns>The pixel format.</returns>
PixelFormat GetPixelFormat(Stream stream);
We probably can add similar functionalities to IDepthImageFromStreamDecoder.cs too. The existing GetPixelFormat actually uses the same code as my workaround.