The docs are maybe a little confusing since they seem to say that iheight includes stretching:
iheight/iwidth: Size of the output image (may differ from height/width for cameras that require image rotation or have non-square pixels).
Yes, there's potential for confusion here, since the data usage paths may differ.
Some might use LibRaw::raw2image() and then process the pixels (already composed into 4-component pixels) themselves, accessing imgdata.image.
In this case, iwidth and iheight are correct (describibg imgdat.image[][] dimensions), even when using half-interpolation.
And some might use LibRaw::dcraw_process() and then NOT use dcraw_make_mem_image() for 3-component output array generation, but directly access the 4-component one.
I agree, iwidth/iheight should be adjusted internally to match new imgdata.image dimenistions if LibRaw::stretch() is used internally.
Most likely, all old library users have long since solved this problem (depending on how they use the data), but probably every new user has a chance of stumbling in this place.
Yes, there's potential for confusion here, since the data usage paths may differ.
Some might use LibRaw::raw2image() and then process the pixels (already composed into 4-component pixels) themselves, accessing imgdata.image.
In this case, iwidth and iheight are correct (describibg imgdat.image[][] dimensions), even when using half-interpolation.
And some might use LibRaw::dcraw_process() and then NOT use dcraw_make_mem_image() for 3-component output array generation, but directly access the 4-component one.
I agree, iwidth/iheight should be adjusted internally to match new imgdata.image dimenistions if LibRaw::stretch() is used internally.
Most likely, all old library users have long since solved this problem (depending on how they use the data), but probably every new user has a chance of stumbling in this place.