image capture: no file saved when selected rectangle is 'negative'
A slight problem while using the image capture feature, to snip sections of a score and save them as PNGs: the Save dialog opened and operated as usual. However, no actual file was saved.
Turned out this was happening when the left edge of the marquee frame had been dragged past the right edge. I had hoped this would be a way to cut a stave (in continuous view) into sections which could, in principle, be pasted together again to recreate the original stave. The idea was to leave the right edge of the frame where it was, to serve as the left edge of the next capture.
The attached files were successfully created after I discovered why some of my efforts failed to save.
Comments
I'm not quite understanding your goal here. You want a PNG file of a single long staff? Best way to do that is go back to page view and actually set up your page to the desired height and width, then File / Export. Or the image capture tool.
As it is, though, I would say probably we should simply disallow negative boxes in the image capture tool to avoid the issue you saw.
In reply to I'm not quite understanding… by Marc Sabatella
OK I'll try to explain! I was trying to create the attached graphic, by cut and paste. It's an analysis of Thelonious Monk's use of a 5-note motif in 'Straight, No Chaser' - to appear shortly on my blog jazzmodes.com.
What I tried (it didn't work) was 'walking' the marquee along the stave, each time moving the (current) left edge past the (current) right edge, then capturing another image. That way, I thought, I won't miss anything and won't copy anything twice. Also, the work of selecting the clips will be halved.
All seemed to be working fine until I noticed that half the image files didn't show up in the target folder.
IMHO the most elegant solution is not to inflict more error messages on the user, but to make sure that clips save correctly, whether x2-x1 and y2-y1 are positive or negative (where [x1,y1] and [x2,y2] are the coordinates of opposite corners of the marquee rectangle.) Do the developers think that could be arranged? :)
Musescore 2 is a great program, by the way (nudge nudge).
In reply to OK I'll try to explain! I… by jazzmodes
Funny enough this just works properly in current master (which will become 3.0 one day), only in 2.x the issue is seen, where it silently(!) does not create the files.
I believe that actually it should be easy enough to allow for this by normalizing the rectangle (using
QRectF::normalize()), as far as I can see it would be a 2 line fix in master (which doesn't need a fix), unfortunately the code for 2.x looks quite different, but it should be possible there too, just be slightly more involved?Looking some more, the 2 places to add a
.normalized()to would be mscore/fotomode.cpp, line 633 and line 635, the 2 places where a file actually gets saved. No warranty, entirely untested...So is seems that to detect the situation and bail out with an error message is more work than actually just making it work.
Mind to file this as an issue?
In reply to Funny enough this just works… by Jojo-Schmitz
OK Jojo, I'll raise it as an issue and hope it's as easily fixed as you suggest. If not, I guess we all wait for 3.0.
I have put a short video at https://drive.google.com/open?id=1c0RQ9iHcFyIlPXI4pNiZPTWDcbRUjTtW which shows how the issue arises. Marc, that may answer your remaining questions.
In reply to OK Jojo, I'll raise it as an… by jazzmodes
Thanks for the video, but actually, it still doesn't hep me understand the significance of making sure the end point of one lines up perfectly with the start of the next. I had thought it was because you wanted to then re-paste them together into a facsimile of Continuous view, but it doesn't seem you are doing that at all.
In reply to Thanks for the video, but… by Marc Sabatella
I ran into some unexpected behaviour in the software. Developers are on the case. What I was trying to do isn't really that important. But you're right, it didn't involve physically pasting the clips together.
[edit] ...but if you're interested from the point of view of jazz rather than graphics operations :) ...
Well I guess you recognise the tune (Straight, No Chaser). The point I'm trying to make is that Monk constructed the whole tune from twelve rhythmically displaced iterations of the same 5-note motif. (Nine instances are identical apart from their placing in the measure; one is cut short, and two fit chromatic scale fragments to the motif's rhythm.)
There are just 7 'glue' notes. The other 59 notes in the piece come from the motif. To show this graphically, I chopped up the tune and lined up all 12 copies of the motif in a column so you can match them note for note.
In reply to I ran into some unexpected… by jazzmodes
Well, it's important if you want help actually achieving your goal today :-) We need to understand your use case in order to suggest how to work around this bug most effectively. If you've already got it covered, great, but if not, we're ready and willing to help.
In reply to Funny enough this just works… by Jojo-Schmitz
Hmm, appending that
.normalized()resulted in a file being saved, but it is empty.Master uses canvasBoundingRect() and before that used bbox() rather than rect(), using these still doesn't work, and no matter whether there's a "negative" size or not, so neither of this is the solution
Edit: all wrong, my approach (of appending that
.normalized()) seems to work just fine, apperently just my png viewr can't deal with transparent files (the viewer having a black background :-( )Also I found a 3 place that most probably needs that.
I've created an issue for it now: #268465: image capture: no file saved when selected rectangle is 'negative'
In reply to Hmm, appending that … by Jojo-Schmitz
I'm sure you are not far from a solution.
I think we may have doubled up in creating issues for this. I am sure the system can cope with that (;
In reply to I'm sure you are not far… by jazzmodes
Yep, I just marked it as a duplicate. You can try the build (if using Windows), see https://ci.appveyor.com/project/MuseScore/musescore/build/1.0.115/artif…
In reply to Hmm, appending that … by Jojo-Schmitz
I'm case you didn't notice: the issue is fixed in the latest 2.2 development builds
In reply to I'm case you didn't notice:… by Jojo-Schmitz
[happy face]
In reply to OK I'll try to explain! I… by jazzmodes
I'm still not really understanding how that graphic required "walking" - each little clip is very short and should have easily been captured within a single window. Maybe it would help if you attached the actual score you were working on. Anyhow, I'm just trying to help you accomplish your goal more easily.