Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make benchmarking work with higher resolutions #10

Open
desecnd opened this issue Dec 18, 2023 · 0 comments
Open

Make benchmarking work with higher resolutions #10

desecnd opened this issue Dec 18, 2023 · 0 comments

Comments

@desecnd
Copy link
Contributor

desecnd commented Dec 18, 2023

Currently the tool works with specific resolutions and aspect ratios. It would be useful to make it work with higher resolution images as most floor plans tend to be larger then maximum possible supported version at current state.

Partialy this problem was issued in #7 - as at current state, large images are thumbnailed to specific resolution but keep the original one in GUI which produces invalid region with blue color, example shown below:

bad_pygui

This problem is partialy covered by #9 , but there are still problems with navigation inside the GUI - as far as I am concerned, right now there is no option to zoom in / out or move around the screen, which is a problem with resolutions bigger than the screen size.

As mentioned in PR, following are two different ideas that can be took into account:

  1. Make moving around the floor plan possible:
    • Floor plan is loaded in full resolution, GUI is showing only a part of it
    • Moving around the floor plan is done via keys / mouse / etc.
    • Adding a point adds a real coordinates to .json (so x, y from loaded image)
  2. Load image with "scale" parameter
    • Image is loaded but scaled according to chosen or semi-automagically calculated ratio
    • There is no need to move around the image, as all fits the screen
    • Adding a point adds "scaled" coordinates (x * x_scale, y * y_scale) on real image. This means that we're loosing a bit of accuracy, but I don't think its a problem in this case.

There are possibly other approaches that can suit better to this issue, theese 2 are the ones I think are possible to implement. The first one is definitely harder, but probably makes use of the program easier. The second one on the other hand is much easier to implement, but more annoying to use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant