Menu
▾
▴
#3064 png save has wrong component indexes in Tk8.6
open
8
2013-02-05
2013-02-05
No
I create a new PNG photo image from Tk and then fill it from C with Tk_PutPhotoBlock. Writing it to file then results in wrong color component indexes. It seems to put the RGBA indexes (blockPtr->offset) in function EncodePNG as 1 2 3 3 when after some tracing into the code should really be 1 2 3 0. (not sure why it is not (0 1 2 3) though
Adding this at the start of EncodePNG seems to fix it but I'm not sure about the implications for the various other types of PNG
blockPtr->offset[3]=0;
The indices probably ought to be {0,1,2,3} (remember, the array is zero-indexed) or there is something really odd going on; that's the offsets that Tk always uses internally for *its* data, and they're hard-coded in tkImgPhoto.c.
How is blockPtr->offset[0..3] filled in your original
Tk_PhotoPutBlock calls? If the original image
doesn't contain transparency data, blockPtr->offset[3]
should be set to -1 or equal to blockPtr->offset[0]
The blockPtr->offset is filled as 0,1,2,-1 since I have no transparency in this case. I totally agree that it should be { 0 1 2 3 } within the EncodePNG but the indices get mixed up somewhere because I had to force 1 2 3 0 to get the right image written. weird !
Looking at ImgGetPhoto (in tkImgPhoto.c) I see some very odd calculations. I've not yet worked out quite what they mean (is it really the case that there's no alpha offset off all the other offsets are non-zero?).