-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
Allow manually changing canvas size #92
Comments
I would prefer to have a separate option for this, leaving the crop as it is and adding new option called Extend Canvas area or Extend Scene like it's called in Qt terms. |
i only can give feedback from photoshop perspective, it is really handy to have it in the crop-tool. |
In Photoshop it's part of the crop tool? I try to align to well known tools, they have usually more experienced people around UI design. It is even simpler to allow it in the crop tool because it's simple removing a restriction |
Interesting, then lets go with the crop. |
Sounds great! Originally, I proposed to rename:
crop
to something like
crop / extend,
to enhance discoverability. But if Photoshop calls all this simply "crop",
I guess it can remain with that name.
Just in case, I also recall the related #91: if easy to implement, it's
quite complementary to this (and useful for other reasons, explained there).
… |
I'm currently looking into this and I'm not all to happy with the combined Crop and Extend, the behavior is kind of strange that sometimes the images is cut of and sometimes not. I'll try now with two separate controls, one that can crop the background image, which cannot be extended beyond the background image (this is what we have already) and one extend or resize canvas that can increase the canvas size but cannot be shrinkt below the background image size. Later on we might add here a selection for the canvas fill. |
The name could be something like "Adjust Canvas", that might allow doing other canvas operations here |
I don't see well why you find it strange: one just adjusts freely the
region to get the desired view (as it works in crop tool in Photoshop).
While dragging, one should have visible at any moment the original frame,
just to have that reference on what he is doing.
In fact, sometimes both things (crop/expand) may be needed at the same
time: some side has to be croped (too much was captured there), another
side has to be extended (e.g., in order leave room for annotations and
controlling the extra margin they will have there).
In any case, if you finally prefer implementing this with 2 separate
tools, it is also good (the previous scenario can also be done in 2
separate steps).
|
Take for example an Image that you have captured 500x500 px, you open crop, cut one half of it of, the visible image is now 250x500 px and the canvas has the same size. You open the crop tool again, extend the canvas size to be again 500x500, but you don't get the one half of the image back. If you don't cut the half of of the image, you can't see that anything happened, there is not border to show you what part of image is going to get into final image when you export it. Those scenarios confused even me while I was testing the feature. I think keeping it in two tools might be more clear to users what they can do here and what not. That you need to use both tools is probably going to be a rare scenario and yes, might require opening two tools. |
can we have a config for this? only because it's confusing for one it can be helpful for the other |
It looks quite good to me! |
I'm done, give the CI some time to build, the feature should be available in latest continuous build. |
Thank you very much! I've tested it and looks good (although it took me a time to find where the new functionnality was). A couple of things:
|
Good catch, forget about the first point. Will push a change in couple of minutes. Regarding second point, yes, I agree, we need to address that with #91. Let's see how that change improves the visibility and take it from there. I hope I can provide something to test by end of the week. |
Changed pushed, give the CI some time to finish the build. |
God, you're quick! |
It was just a minor fix :) The CI is slow lately, takes ~50min but you're right, can't see the build items. I have triggered it again. I'm working already on #91, I think it looks quite nice. Over that would come the canvas color, what ever you have picked there: |
Curiously, the new build isn't appearing... I'll wait for next year. :-) Your proposal for #91 looks great! I assume that the checkboard represents transparency (as per usual convention). |
Just confirming here that I also tested successfully this one. Many thanks again! As a side note, for your information: I have recently recalled the editing interface of Shutter (the quite good Linux-only annotation tool now discontinued). The editor there constantly "offers" the canvas resize handlers permiting freely enlarging and reducing at any moment: I still find having this option quite convenient and "safe": the handlers are ofered and visible, but one does not have to use them if not interested in resizing the canvas. Limitations there of things that may be often needed:
Both limitations are now covered by ksnip :-) ... although in a indirect modal window. |
FR:
Enhance the crop tool to permit the user not only to crop, but also to extend the canvas of the image (in any choosen direction, as per user preference).
Tool name may be changed for discoverability of this feature.
Initial reason is to control results (specially the extra margin) when doing out of border annotations (see #90).
Besides, even without out of border annotations involved, it is a nice to have feature: being able to directly add external borders (for aesthetics, for controlling the final aspect ratio, ...).
Also related with #91 when implemented (the extension should fill with that chosen color).
The text was updated successfully, but these errors were encountered: