mismatch between size reported after libraw_open_file(), and decoded image size

Submitted by jcupitt on

Hello everyone, thank you for this nice thing.

I had a bug report for this image with libraw 0.21.4-2 (the version in ubuntu 25.10).

http://www.rawsamples.ch/raws/nikon/d1x/RAW_NIKON_D1X.NEF

The size reported by libraw_open_file() is:

(gdb) p raw->raw_processor ->sizes 
$4 = {raw_height = 1324, raw_width = 4028, height = 1324, width = 4024, 
  top_margin = 0, left_margin = 0, iheight = 1324, iwidth = 4024, 
  raw_pitch = 0, pixel_aspect = 0.5, flip = 0, mask = {{0, 0, 0, 0}, {0, 0, 0, 
      0}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 
      0}, {0, 0, 0, 0}}, raw_aspect = 0, raw_inset_crops = {{cleft = 65535, 
      ctop = 65535, cwidth = 0, cheight = 0}, {cleft = 65535, ctop = 65535, 
      cwidth = 0, cheight = 0}}}

But after decoding, height is 2648.

`pixel_aspect` is 0.5 which perhaps means `iheight` needs to be doubled. Should libraw be applying this factor and has a bug here, or is it something I should do? The docs say:

 ushort iheight, iwidth;
    Size of the output image (may differ from height/width for cameras that require image rotation or have non-square pixels).

Forums: 

LibRaw applies pixel_aspect

Submitted by lexa on

LibRaw applies pixel_aspect on postprocessing stage (LibRaw::stretch() is called in LibRaw::dcraw_process())

stretch() call adjusts height or width value.

-- Alex Tutubalin @LibRaw LLC

So I should set my image

Submitted by jcupitt on

So I should set my image height to `iheight / pixel_aspect`? Thanks!

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).

I don't know what your code

Submitted by lexa on

I don't know what your code does, so I don't know what you should do.

If you're doing your own post-processing, you're probably using decoded RAW data only. In that case, it's worth considering pixel_aspect on final rendering

If you're using LibRaw post-processing (LibRaw::dcraw_process) then LibRaw::dcraw_make_mem_image() will do all needed tricks.

-- Alex Tutubalin @LibRaw LLC

The docs are maybe a little

Submitted by lexa on

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.

-- Alex Tutubalin @LibRaw LLC