Separate x/y dilation and fine-tuning

[3gMan]

I may have asked about this before, but is there any chance we can get decimal points for the dilation? Even in-between .5's would work much better since often 1 is too little and 2 is too much. Also, most models require less y-dilation than x-dilation. Separate settings would be great. As it is it works much better to export disparity; import into Resolve and add the differing x/y dilation at exact specs; export and overwrite into the disparity folder; then render in iw3. I am pretty sure the current implementation of dilation only allows full integers and maybe not separate x/y since I tried modifying it previously. Not sure how difficult it would be to change the dilation system.

Thanks for the inpainting btw. Looks like a great start and with only a day or two of training and not much refining yet, sounds like it has great potential!

[nagadomi]

It is easy to split edge dilation setting into the x and y axes.
I recently thought maybe just x would be fine, but considering depth errors like hair, I decided it's safer to keep both and left it as is.

The reason it is an integer value is that the process is performed in pixel units. Since it is applied on the depth resolution, dilating by 1px at a depth resolution of 518 results in about 4px dilation on 4K output.
By performing dilation at the output resolution, finer adjustments become possible, but the processing load will increase slightly.

[3gMan]

Personally I think separate x/y dilation would be great. I'd for sure use the finer adjustments as well, but I posed the question on that in the iw3 discord to see what others would want. Of course final decision is yours. Thank you

[KolaKater]

Personally I think separate x/y dilation would be great. I'd for sure use the finer adjustments as well, but I posed the question on that in the iw3 discord to see what others would want. Of course final decision is yours. Thank you

I agree with you , I think your reasoning is solid and well thought out, as I also did some experiments myself. Separating x and y dilation makes a lot of sense, especially for preserving the natural appearance of foreground and background elements in 3D conversions. The horizontal dilation helping maintain object shape while vertical dilation can distort background lines is a practical observation that reflects real-world usage.

It’s a technically sound suggestion that could improve the flexibility and visual quality of iw3’s output. If Nagadomi is open to community feedback, your argument definitely deserves serious consideration.

It's essential to separate the x and y dilation settings in iw3. Since iw3 is designed to convert 2D images or videos into 3D side-by-side format, the horizontal (x-axis) dilation often needs to be more pronounced than the vertical (y-axis). This is especially true for maintaining the integrity of foreground objects—larger x dilation helps preserve their shape and prevents distortion when viewed in 3D.

On the other hand, increasing y dilation can lead to unnatural results, particularly in the background. Vertical lines, such as those found in architecture or scenery, can appear warped or misaligned if y dilation is too strong. By allowing independent control over x and y dilation, users can fine-tune the depth effect and achieve more realistic and visually pleasing 3D conversions.

I believe this flexibility would significantly improve the output quality and give users more creative control, especially when working with complex scenes. Hope soon we will see something like Edge Fix X and Edge Fix Y

[nagadomi]

Yes, I plan to separate dilation into x and y components.
My only concern is maintaining compatibility with the CLI options and the exported YAML files.

[KolaKater]

Thank you Nagadomi. I understand your concern about keeping CLI options and YAML files compatible.

In iw3, the Edge Fix feature can work similarly to how image resizing works in Photoshop. Users can either input a single value to apply the same dilation to both X and Y directions, or they can specify separate values for X and Y to fine-tune them independently. This flexibility is quite useful, especially for 2D-to-3D conversion tasks where horizontal dilation (X) often needs more control than vertical (Y).

So if the CLI and YAML can support both modes — unified and separate — that would be ideal.

Maybe it will look like this:

[nagadomi]

Changed in #540

[TeeJay-NLD]

Hi @nagadomi,

Thanks. But I am using (of course) the inpaint-branch and my GUI did not change to show the changed "Edge fix" combo box. Of course I updated the branch. What did I forget to do?

Warm regards... TeeJay-NLD

[nagadomi]

iw3_inpaint branch has already been merged into dev and will be deleted.
Please use the dev branch.

[nagadomi]

I mentioned this in this comment, but most people probably haven’t noticed.
I want to let iw3_inpaint users know that they should switch back to dev, but the only way to do that is by deleting the iw3_inpaint branch to trigger an error.
Deleting it right away would be too sudden, so I plan to wait a bit before doing so.

[TeeJay-NLD]

... swichted to dev. All fine now. Many thanks!