Non-square EXR encodes with incorrect texture height

[krispya]

Using 4.3.0-alpha3, I am attempting to encode an EXR file with 4096x2048 dimensions. The result looks like this:

However, if I resize the same EXR to be square (2048x2048) then it encodes just fine.

I would expect the encoded texture to match with the power of 2 dimensions just fine.

This is my command line:

ktx create --format R16G16B16A16_SFLOAT sky_linekotsi_23_2048.exr sky_linekotsi_23tt.ktx2

Here are the files for reference: https://www.dropbox.com/sh/u2htkdglhjopogy/AAAzXXedlJCm-THj1EWgYRBoa?dl=0

[MarkCallow]

Please add the non-square EXR to the dropbox. It has only a non-square Radiance file and the square EXR. We need to see the input you used.

[krispya]

My mistake, I dragged the wrong file over. It should be there as sky_linekotsi_23.exr.

[MarkCallow]

The result looks fine to me.

I am using a slightly later version of ktx create but the change logs between 4.3.0-alpha3 and what I am using do not reflect any change that might have fixed this problem except perhaps this one:

commit 682f456de1402c2256cdc2b2fe21c0e8c54b4915
Author: Cs<C3><A1>sz<C3><A1>r M<C3><A1>ty<C3><A1>s <VaderY@users.noreply.github.com>
Date:   Thu Jul 13 13:38:20 2023 +0200

    Fix incorrect index calculations in image conversions (#735)

    Fixes #733. Fixes #736.

@aqnuep please comment.

[krispya]

Thanks for checking on this so fast. In a sense this is a big relief and also not. Now I need to figure out why my environment is making incorrect textures. 😆

[aqnuep]

There was at some point an issue, where the width and height parameters within the EXR path in the image input library were accidentally flipped somewhere, which was fixed a couple of months ago. I expect this was caused by that.

[krispya]

I can confirm this is fixed with a build from main. I'm looking forward to a new alpha being cut!