Okay ! Haha, way better already ! Here is the same picture but with v0.4.3

Small box area to cover just the text. Does nicely though has some issues

And now with the same large encompassing box. This is where your new technique shines. It’s miles better compared to 0.4.2! It cleanly removes the title and the message box is cleanly preseved

Proposed Next Step

Implement coordinated text placement.

In Dynamic OCR Mode, store the starting position of each paragraph block. This information should be retained and applied during translation output.

Why this matters:

• Many UI elements (menus, item descriptions, system messages) rely on precise text placement to make sense visually.
• Translated text may differ in length, but starting position is often consistent and sufficient to maintain structure.
• Proper alignment avoids overlapping or misaligned text that can make UIs confusing or unreadable.

Suggested Implementation:

• During Dynamic OCR, record the XY-position of each detected line or block.
• When rendering the translation, align output based on these stored positions.
• Optionally allow slight dynamic adjustments if translated text blocks risk overlapping.

This would bring translated UI elements much closer to the original layout and greatly enhance the clarity and usability of real-time game translations. Thank you again for the amazing progress in 0.4.3 🙏

Tested 0.4.4 and here are the results

The new addition of only having the background replaced where new text is placed is genius.  
 
 
Now, one issue is that the function that decides which background colour to pick sometimes makes.. odd choices.

As we can see here, the UI background element is “Tan” (RGB 241, 236, 220), but it decides that the translation background should be “Light Blue”? (RGB 223, 238, 244).
 

Proposed Workaround : High Contrast mode

While in an ideal scenario, the logic would always pick the most appropriate background color, to improve readability in edge cases without compromising the dynamic system, I suggest adding a toggle in the settings for an optional High Contrast Mode.

Why this matters

• Does not rely on complex background color detection logic, keeps the overlay readable even when the background detection fails.
• Provides a safety net for users who prioritize clarity over aesthetic subtlety.
• A similar solution already exists in the default capture window. This builds upon it with a simple binary threshold and two static styles.
• Improves accessibility of the app.

Suggested Implementation

• IF [Detected Background Luminance] is < 50% gray → Overlay shows white text on a black background
• IF [Detected Background Luminance] is ≥ 50% gray → Overlay shows black text on a white background

To prevent too high of a contrast :
White is RGB 222, 222, 222
Black is RGB 18, 18, 18

This would be a practical compromise between automation and user control, and it gives end-users a way to ensure legibility in any scenario.
Let me know what you think!
🙏

Test with 0.4.5

Now the background colours are correct! 🙌

 
This has definitely improved a lot since 0.4.3.

You are already aware and we have talked about the font colour and padding still having issues so I won’t repeat them here. But: Progress!

Further 0.4.6 testing

❌ Without High Contrast Mode

✅ With High Contrast Mode

And now we are back to the last, arguably the toughest, piece of the puzzle : the background removal algorithm itself.

As we can see in this example, high contrast mode does not address the underlying issue in this scenario (the background removal algorithm grabbing pixels from nearby UI elements, already mentionned in above discussion).
We can even see the High Contrast mode being led into error because the background removal algorithm is rendering a lighter than reality background for the translation of the “E” button prompt.

Testing 0.4.7

I can happily confirm that the original test case has been successfully achieved with flying colours. 🎉  

0.4.7 : Algorithm 1 = PASS ✅

0.4.7 : Algorithm 2 = PASS ✅

  (All pictures were taken with “High Contrast” mode enabled)
  As we can see here, in 0.4.7, both are now satisfactorily passing the original test.

NOTE: There is some minor artifacting with the “E” for example. As the on screen UI is round and GameTranslate applies it’s background removal in a rectangle, but nothing distracting from the translation experience. I suppose this will eventually be ironed out with further improvements to the algorithm.
NOTE 2: The only difference I can see with the 2nd algorithm is that it close, it matches the original text font closelier. 🤷

Godnoken said: […] It is much less destructive & works really really well in all cases apart from extremely thick & large custom fonts

And to this I must concur. I have tried 0.4.7 on another test case and the results were indeed as described..

❌ 0.4.7 with thick and large fonts

Interestingly, it seems to have issues with the letter T more than others. 🤔
 
 
Solid progress nonetheless! We went from a distracting user experience to minor visual glitches. This certainly feels more polished. 👍