Welcome to iraf.net Friday, April 19 2024 @ 11:35 AM GMT
jturner |
02/10/2013 02:58AM (Read 1778 times)
|
|
|
Status: offline
Registered: 12/29/2005
Posts: 165
|
This is similar to the apextract bug I reported a few days ago, but seems to be new in 2.16.One of our tests was crashing with an overflow error after imshift had introduced corrupt pixel values of 10^26 in the first row of an image. I've tracked this to another (sometimes) uninitialized variable in the file imio/imrbpx.x. The variable "ncp" is used at L123 of imrbpx to increment the array index "op", but its value is only set when the "if" condition at L98 has not been met and the "else" has been executed. For negative shifts (at least this case), the "if" gets executed on the first loop iteration, so ncp is uninitialized. The value of ncp then gets corrected by the else block at the next iteration and (for me) that value then gets retained between one imrbpx call and the next, thus only the first line of the image gets corrupted.I believe I have fixed this in our installation by moving "ncp = sz_pixel" at L102 to L75 (above the "do i = 1,3" loop); our imshifted image now looks fine.Thanks,James.
|
|
|
|
jturner |
02/10/2013 02:58AM
|
|
|
Status: offline
Registered: 12/29/2005
Posts: 165
|
It occurs to me that my fix probably isn't quite correct on 64-bits, is it? I think the couple of lines that double the pixel size if "SZ_INT != SZ_INT32" at L108 would also need moving.
|
|
|
|
fitz |
02/10/2013 02:58AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Hi James,I agree there is an initialization problem with the 'ncp' variable and have fixed this in the next release. The 'SZ_INT != SZ_INT32' check has to do with converting between the integer pixels in the disk file (which are always 32-bit) and that used in the imio code (where integers can be 64-bit and so need packing/unpacking when moving between disk and memory), I believe this part of the code is correct.-Mike
|
|
|
|
jturner |
02/10/2013 02:58AM
|
|
|
Status: offline
Registered: 12/29/2005
Posts: 165
|
That's great, thanks.The reason I queried the SZ_INT part was just that it also changes the value of ncp, which I believe would then get used for incrementing the next of the 3 iterations by a different amount from the previous iteration(?) -- but I haven't really tested that behaviour as we're always using 32-bit binaries so I only mentioned it in case my previous suggestion was incomplete/misleading.By the way, I have seen some corruption due to this in a different test that was over the whole image rather than just the first row, which also went away after initializing ncp, just in case you get similar reports...Cheers,James.
|
|
|
|
| |
|
Content generated in: 0.13 seconds |
|