CImageDecoder or CFbsBitmap perform padding?

[NevenS]

Hi,

I have been using CImageDecoder and CFbsBitmap quite successfuly to capture snapshots and then decode them. That means that the CCamera provides a HBufC8 pointing to the EXIF JPEG data of the snapshot and CImageDecoder provides the corresponding CFbsBitmap. The camera always produced 24bpp BGR images, and the decoder's resulting bitmap had DisplayMode EColor16M (True Color 24bpp). This was done on N82 (Symbian 9.2).

Recently I added the functionality to bypass capturing from camera and load from a file. That means that the HBufC8 has been filled with data from a JPEG file on a phone. This also works fine, or at least it seemd so.

After some hours spent pondering why the serialized images from later stages of the program looked distorted, I have traced the problem back to the CImageDecoder and/or CFbsBitmap. Note that no errors, no leaves etc. occured!



Namely, let CFbsBitmap * bmp be the "correctly" decoded jpeg, and {W,H}={547x69) the dimension of the JPEG, then:

TInt iBitmapSize = bmp->Header().iBitmapSize;
TInt iBpp = bmp->Header().iBitsPerPixel;
TSize iSizeInTwips = bmp->Header().iSizeInTwips;
TInt iStructSize = bmp->Header().iStructSize;
TSize iSizeInPixs = bmp->Header().iSizeInPixels;
TDisplayMode dm = bmp->DisplayMode();


I get:

iBpp==24, Ok
iSizeInTwips == {0,0}, Ok (don't know what it is)
iSizeInPixs == {W,H}, Ok (same as the Jpeg)
dm == EColor16M, Ok
iStructSize == 40
iBitmapSize == 113476

A bit of a sanity check, if everything is ok, then it should be equal:

(1) iSizeInPixs.iWidth*iSizeInPixs.iHeight*iBpp/8+iStructSize==113269 =?= iBitmapSize==113476

Well it's not, at least not in this image.
I discovered that if I add an offset ofs to iSizeInPixs.iWidth, then (1) might become true.
For the above image and ofs==1, (1) is true.

(iSizeInPixs.iWidth+ofs)*iSizeInPixs.iHeight*iBpp/8+iStructSize == iBitmapSize, for some ofs

Depending on the image, ofs is 0, 1, 2, 3.
And the "right border" of the image then contains white pixels (for ofs > 0) (i.e. no distorted pixels etc.).
When I serialize the image with this "extended" iWidth, then it's correct when I open it (not distorted).

My "solution" is to create another CFbsBitmap, which is explicitly wider than the decoded one and then copy
the pixels into it (then the Header's width corresponds to the pixel data).


Oh, I access the pixels with bmp->DataAddress()




What's going on?
Padding?
Did I miss somehting in the documentation?
Is it because the JPEG image has no EXIF data?

Thanks in advance

[Sorcery-ltd]

Hi,

Might your observations be consistent with the scan-lines being padded (on the end) to a 4-byte boundary? ARM processors have some rather strict alignment rules that would make this desirable...

Mark

[NevenS]

I suspected something like that, especially since the padding did not exceed 3 bytes.
But I am shocked that the underlying header does not reflect this padding, it cannot be that I have to derive it by noticing that one part of the information in the header does not correspond to the other half (e.g. in my case iSizeInPixs.iWidth*iSizeInPixs.iHeight*iBpp/8+iStructSize != iBitmapSize).

Either iSizeInPixs.iWidth should be increased accordingly or there should be another member, e.g. SEpocBitmapHeader::strideByteWidth which tells me by how many bytes do I have to increase the DataAddress() pointer to get to the next line..

Or there is such a member, but I failed to see it in the documentation..

Thanks

[Sorcery-ltd]

Yes, it is documented - see the ScanLineLength() method of CFbsBitmap:
http://www.symbian.com/developer/tec...canLineLength()

Mark

[NevenS]

ah dammit..

thanks again