Bug found in 'Accord.Imaging.Filters.FastBoxBlur' and fix it #798
Conversation
Bring fork uptodate
Use of 'Accord.Imaging.GetPixelFormatSizeInBytes()' was wrong, cause of traverse the image incorrectly and attempted to read or write protected memory.
|
Hi Hashem, Ops, the effects of my changes had not caught by the unit tests. Sorry about that. However, if the pixel size for 8-bpp grayscale images is 1, then wouldn't the size for a 16-bpp grayscale image be 2 instead of 3? I think that the problem is not in the use of GetPixelFormatSizeInBytes() function, but rather in line 188 (and related) where the algorithm is multiplying that value by 2. Also, maybe the code should not be using a byte*, but rather a short* which in this case would have the correct size of 2 bytes. Thanks a lot again for the contribution and sorry for breaking it, but please let me know what you think about those changes! Regards, |
|
First things I think the correct result is the matter! Test with 8, 16, 24 images, that's okey. If you like to change with the other way, correct result is the matter :) However, for this context pixel size set to 1 if we have a grayscale (8 or 16) image and set to 3 if color(32, 48). |
|
Hi Hashem, I understand. I think it is also better to restore the broken functionality as soon as possible. Thanks a lot for the fix! Regards, |
2 participants
Hi dear Dr,
When developed 'FastBoxBlur' filter On Jan 8 was a correct and tested code, but today when use it, give this exception:
Finally I found some codes in changes! I used this before:
var pixelSize = ((image.PixelFormat == PixelFormat.Format8bppIndexed) || (image.PixelFormat == PixelFormat.Format16bppGrayScale)) ? 1 : 3;but now see this in 140 and 219 lines:
int pixelSize = image.GetPixelFormatSizeInBytes();Regards,
H.Zawary