-
Notifications
You must be signed in to change notification settings - Fork 17
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
RectanglePoints confuses me #69
Comments
I think you're right, it should be the other way around like you proposed. Mixing array indices and image coordinates can be confusing sometimes. |
Agreed. I also found this confusing (#40 (review)) so I'm supportive of a redesign. Just that I myself probably don't have the time to do it in the near future. A new package seems a more doable approach to make it less breaking. If there's anyone who wants to do it himself, I'll be very happy to comment and review. |
Thank you for looking into this @johnnychen94 . Would it be OK to just change the implementation of I also vaguely recall that there is a way to search registered packages for dependences, so it should also be possible to submit pull requests to those affected. |
Might not be so trivial. At least we have to go through the entire codebase to ensure all types use the same coordinate convention.
JuliaHub has this feature https://juliahub.com/ui/Packages/ImageDraw/Gb86X/0.2.5?page=2 But keep in mind that there are potentially many non-registered projects, including the JuliaImages documentation https://github.com/JuliaImages/juliaimages.github.io. Thus a safer way to introduce this fundamental breaking change is to create a new package with a similar API, and let people actively switch to the new package. It's not an easy work to track down to this coordination swap change. Another reason that I'm in favor of rewriting is, that rewriting this package with Graphics or GeometryBasics dependencies could make it easier to introduce more features or compose with other ecosystems. |
When using
CartesianIndex
to define a rectangle, the resulting rectangle is not bounded by the pixels mentioned in theCartesianIndex
.Example:
But
Point(1, 2)
is the pixel withCartesianIndex(2,1)
.The definition says:
To me it would make a lot more sense to define it as
Of course this would be breaking.
Am I just thinking about this the wrong way?
The text was updated successfully, but these errors were encountered: