Krita transform tool produces aliased edges

[Grum999]

@Deif_Lou

The reason is that there is 2 rendering paths, at least using the accurate option: one is used for the “inexpensive/fast” preview and the other for the high-quality transformation. The fast one always performs bilinear sampling (even if the filter is set to nearest neighbor in the options) and is used for example when moving the handles. Then, after some seconds of inactivity, the high-quality rendering is triggered.

Wow thanks for explanation!
It’s more clear to me now about why there’s a second process 3second after first rendering

@Deif_Lou

The issue was purely on how the sampling was implemented. There was an issue on how the dst device points were mapped to the src device pixels. It didn’t map the pixel centers, but the corners so some shifting was noticeable

I saw there was a shift but sincerely I was not able to understand from where it came (and trying to hard code +1px to check if it fix the problem, didn’t change anything )

@Deif_Lou

I made a draft MR

Aah thanks!
I’ll take a look on it this week-end, I’m really curious to understand how it works.

@Deif_Lou

This is an issue that Dmitry would have to solve i’m afraid.

This comforts me not being able to understand what’s happens here

Anyway, many thanks for explanation and MR!
In addition, I’m curious to now if there’s a reason why first (fast) render use workers to parallelize process, and not the second (high quality) one

Grum999

[Deif_Lou]

Both are asynchronous, so that the ui does not get blocked. But to get to the worker setup code for the high quality one you have to follow some function calls.

Don’t ask me details because i spent the morning getting Dmitry to explain the code and i still am confused

[Grum999]

@Deif_Lou

Both are asynchronous, so that the ui does not get blocked

On my side, for what I see on big 16000x16000px image (and also from traces I’ve put when I tried to understand the situation)

• The first (fast) transform use workers to parallelize render from tiles (512x512 it seems)
  – It’s fast
  – UI is not blocked
  – We can see tiles being updated during process
  

  
  Example: rendering tiles is parallelized, UI is not blocked (can switch tab in docker for example)

• The second (HQ) transform seems to not be parallelized
  – It’s slower than fats method (even using same bilinear algorithm)
  – UI is blocked
  – Transformed render is updated in one-shot after complete transform
  

  
  Example: rendering tiles is not parallelized, UI is blocked (can’t switch tab in docker for example)
  First we see here the bilinear being applied, can switch between tabs
  *Then, we see the progress bar in docker: HQ in on progress, can’t switch between tabs in UI and at the end, when all tiles are processed we see the HQ updated (used a nearest-neighbor here to see the difference)

@Deif_Lou

Don’t ask me details because i spent the morning getting Dmitry to explain the code and i still am confused

Don’t worry, it was in case you had the answer
I spent most of my last saturday and part of sunday on it, without understanding it…
You understand the situation here better than me so I know what is the feeling to be confused about how this work

Let’s wait for Dmitry feedback about this

And the most important is the ability to fix the aliasing stuff, the parallelization is another subject I think.

Grum999

[freyalupen]

Here’s what I get with commit 5ae24a56. The edge is no longer aliased, but the image still jumps 1px to the left. (That is, the temp preview is 1px to the right of the final render.)

[Reptorian]

@freyalupen

(That is, the temp preview is 1px to the right of the final render.)

That was already a bug before this commit.

[freyalupen]

I know, I was just demonstrating which issue was fixed and which was still there.

[Deif_Lou]

@freyalupen and @Grum999 see if you can put your findings on the mr, so that Dmitry sees them.

Yes, the fix was separated in 2 parts, 1 the aliasing artifact which was fixed and the other part is related to sampling.

@freyalupen the issue you talk about I didn’t find by rotating/scaling. It may be that it only happens with some combinations of those and maybe also translation. I’m not sure if it could be just rect computation related or if the sampling issue is involved. Just write in the mr please. And maybe share the file.