Alexander Karpinsky

It can't be duplicate of #9096 since INTER_NEAREST_EXACT is a result of discussion in #9096. If there is an issue in INTER_NEAREST_EXACT, this is a new issue.

> The story about resize compatibility across the libraries is pretty old. Basically this is not a story about compatibility, this is story of wrong behavior. > Bit exact nearest...

> a default that does not deviate from the current behavior? Current behavior is sending multi-gigabyte memoryview from locals (with no success). I doubt anyone relies on this.

So your code suggestions are? (except that it's obviously should be rebased)

For me it also correct and even intended in some situations. Resizing is done separate in directions, with clipping the source for the second pass will be algorithmic incorrect even...

@rominf Could you clarify your request, do you mean reading? @benyissa as I know, none, so you can start just right now.

Looks like `wait --for=condition=Ready` doesn't work for jobs. Any workaround for this?

I see there is "API to list all transformation properties" was added by @farindk in https://github.com/strukturag/libheif/commit/602baf497095e717b76a9ff45bb63b7ce4152bca (v1.16.0) without any pull requests, discussion. Also there was no feedback on this pull...

@bigcat88 1. You can easily get `heif_image_handle` from `heif_context` and `heif_item_id`. Yan can't get `heif_context` if you already have `heif_image_handle`. `heif_image_handle` is more universal, its definition of universality. 2. You...

> Concerning returning the transformations in a 'canonical' order: this may have some nasty consequences. Just for the record, I don't have any questions to this part. It's up to...