Welcome to iraf.net Friday, March 29 2024 @ 11:37 AM GMT


 Forum Index > Help Desk > General IRAF New Topic Post Reply
 IMIO bug in 2.16 when using boundary extension
   
jturner
 02/10/2013 02:58AM (Read 1773 times)  
+++++
Active Member

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.

 
Profile Email
 Quote
jturner
 02/10/2013 02:58AM  
+++++
Active Member

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.

 
Profile Email
 Quote
fitz
 02/10/2013 02:58AM  
AAAAA
Admin

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

 
Profile Email
 Quote
jturner
 02/10/2013 02:58AM  
+++++
Active Member

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.

 
Profile Email
 Quote
   
Content generated in: 0.08 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login