site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi Darrin: Brad On Aug 10, 2008, at 9:46 PM, Darrin Cardani wrote: Darrin On Aug 10, 2008, at 9:41 PM, Brad Wright wrote: Thanksi Steve: Brad Wright On Aug 10, 2008, at 9:15 PM, Steve Christensen wrote: |<- 16 x width ->||<- 16 x width ->| |<----------- rowBytes ----------->| row 0 |<---- upper --->||<--- lower ---->| row 1 |<---- upper --->||<--- lower ---->| ... row 719 |<---- upper --->||<--- lower ---->| or this: |<- 16 x width ->||<- 16 x width ->| |<----------- rowBytes ----------->| |<--- upper ---->| row 0 |<---- lower --->||<--- upper ---->| row 1 |<---- lower --->||<--- upper ---->| ... row 719 |<---- lower --->||<--- upper ---->| On Aug 10, 2008, at 8:20 PM, Brad Wright wrote: Thanks Steve: Brad On Aug 9, 2008, at 11:45 PM, Steve Christensen wrote: On Aug 9, 2008, at 6:29 PM, Brad Wright wrote: [myBitmapImage width] == 720 [myBitmapImage height] == 240 [myBitmapImage rowBytes] = 23040 The image format is Float and 32 bit wide. -- Darrin Cardani dcardani@apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... If it was two rows stacked in a single rowBytes, I'd see a different pattern in the image. In this case the image suppose to be 720 wide, but the actual pattern in the bytes shows that it 1440 wide. The width and height are inconsistent with what is actually contained in the image. It's reporting 720x240 in the FxImage for width and height, but actual contents the memory is consistent with 1440 wide. To test this, I ran a color bar test pattern across the image and the memory pattern is consistent with 1440 wide. If it were double stacked in a rowBytes you'd see a duplication of color bar information. In this case, I'm only seeing a 1/2 of the color bar pattern in the first 720 pixels. If it were row 1 and row 2, the entire color bar pattern would be contained in the first 720 pixels and it would repeat in the next 720 pixels for the next row. This isn't the case as far as I can tell. Brad, What is the field order of the images you are receiving? What are the width and height? Steve's analysis is correct. FCP will often point you to a bitmap which is as many bytes wide as 2 scan lines, one of which is an even field and one of which is an odd field. Actually, I did some analysis on the image being returned. I actually walk the image a for loop and the values are consistent with a 1440x1080 image. I did this by running creating test patterns for the image, so I can see where the values should line up in memory. In this particular case, the values are consistent with 1440 pixels wide and not 720. I'm testing with Final Cut 5.14 and the latest FxPlug API's. It certainly could be broken in this combination. No, you're assuming that 16 x width == rowBytes. That's not always true. What I was getting at was this: 23040 bytes works out to 1440 16- byte float pixels between the start of each succeeding row. Given that you're seeing an image size of 720 x 240 (half of 720 x 480), it looks like you have imageInfo.fieldOrder set to either kFxFieldOrder_UPPER_FIRST or kFxFieldOrder_LOWER_FIRST. (This is also likely the type of input and output images your plugin is being provided.) Thus the bitmap is laid out like this: The rowBytes value is set so that you're using every other line (or one field) of the overall image. You should only be working with the first 720 pixels (or 11520 bytes) on each line since the other half of the rowBytes -may- contain the other field's pixels or it may be uninitialized -- the implementation details are unspecified. That's why you have to respect both the image dimensions as well as the rowBytes: there may be bytes at the end of each row in the image you're processing that are supposed to be left alone.

From what I'm seeing math doesn't quite add up. The row bytes reports 23040 while the image format is 32 bit float. 32 bit float is 16 bytes wide. Therefore, 23040/16 is 1440 which is the width of the sequence settings. So, it looks like something is inconsistent. What value did you supply in imageInfo.fieldOrder? If it contains something other than kFxFieldOrder_PROGRESSIVE, the bitmap may actually contain the entire image, but rowBytes is set up so you only see the pixels in every other row. If that's the case, it's not an application bug since it's doing exactly what you told it to do. I'm seeing possibly wrong values for width and height in an FxImage. The problem happens when I export to a DVC Pro 25 NTSC movie from an HD timeline. My sequence is 1440x1080, and the exported image is 720x480. In the rederOutput function I retrieve the actual image using the temporal image API. if ([tempororalImageApi getInputBitmap:(FxBitmap **) &myBitmapImage withInfo:(FxRenderInfo) imageInfo atTime: (double) renderInfo.frame]==NO)

{ NSLog(@"Failed to retrieve the original Bitmap image\n"); return NO; } Here's the values I get: 23040 is the correct row bytes value for the image if it's at 1440 pixels wide. When I try to process the image using these values in my loop, I get only the first part of the actual image. So it appears that the image is actually 1440 wide instead of being 720 wide. Is this a know bug? Is there a workaround? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/dcardani% 40apple.com This email sent to dcardani@apple.com This email sent to site_archiver@lists.apple.com