Topic: Rethinking how the rail to rail highlights are fitted to the viewport

Report Abuse Report Abuse
Nathanael (Over 1 year ago)
After playing with the new highlight framing system this morning, I have come to wish very strongly that the frame that I draw were fitted to the smallest dimension of the viewer, rather than the largest dimension.

Since the aspect ratio that a user will be viewing the synth at is variable and unknown, it would serve my intent more fully to fit all of what I have outlined into the viewer in a predictable manner, rather than always wondering how much of my selection will actually appear when the highlights are being played back.

Essentially, I prefer how the Share links operate: they pick up on which part of the image the viewer is centred on and how far zoomed into the image I am and that provides a fairly predictable framing for whoever receives the link.
Nathanael (Over 1 year ago)
I've done a fair bit of thinking about applications designed for multiple landscape aspect ratios before and you always want your design to be defined vertically and flexible horizontally.

Thinking over Photosynths being viewed in tall vertical aspect ratios is not out of the question, though... whether just a tall skinny embed on the web or on, say, Windows Phone 7, you'd want highlights to be usable, but also predictable in what they show you, so you'd want just the opposite - horizontally oriented design that is vertically flexible.

This got me away from the notion that rail to rail was bad in itself, and thinking in the direction that the viewer simply needs to know whether its height or width is currently smaller, and fit the rails to the smallest dimension of the viewer, rather than being fit to width or fit to largest dimension as it currently is.
Nathanael (Over 1 year ago)
After a little more testing, it appears to me that these highlights are, indeed fit to width, rather than fit to largest dimension. This seems like a very poor implementation indeed, given the widespread use of widescreen monitors these days.

The tool which we use to outline our highlights is square and forced to be square, but the Photosynth viewer in a maximised browser window on a widescreen monitor gives movie theatre screens a run for their money in terms of wide aspect ratio, meaning that if I depend on the vertical bounds of the frame when 'cropping' (for lack of a better word) my highlights then there is a severe mismatch and I had better be very particular indeed on where the center of that crop is vertically.
Nathanael (Over 1 year ago)
What is truly maddening is that if this vertical centre is off even a little, there is no way to simply edit it in the synth editor. One is forced to completely remove the existing highlight and redraw the bounds - losing the frame of reference in the process, rather than having the existing highlight's frame be displayed again for resizing or repositioning. 

Also useful in this editing-existing-rail-to-rail-highlights scenario would be to keep a shadow frame from the last time the highlight was saved to 'Undo' to, as well as showing me just how far I've moved my currently edited bounds for the highlight.
Nathanael (Over 1 year ago)
In any case, I feel that the majority of users will be viewing these highlights from their desktop computers - the majority of which will be using their monitors in landscape mode, rather than portrait. If the new highlights must not be fitted to 'largest dimension' or 'smallest dimension', but rather simply 'width' or 'height' of the viewport, then my vote is most definitely for height, rather than width.

If, however, you can pull off zooming to fit to the smallest dimension of the viewer, then the door could easily be opened to allowing any rectangular crop, rather than only allowing selections in perfect squares.

I'm open to hearing the other side of the argument, but I'm quite certain about my current position in the matter.
Nathanael (Over 1 year ago)
A proviso is that in the case of general rectangular selections (rather than the current square selections) the only case in which a selected region will not be fitted to the smallest dimension of the viewport is the case in which fitting the rails to the smallest viewport dimension would cause the longest dimension of the selection to transgress the boundaries of the largest dimension of the viewport.
Nathanael (Over 1 year ago)
That is to say, if arbitrary rectangular selections are allowed (and ideally they will be - for a variety of reasons) then if Tony makes a short and wide panoramic selection within one of his great panoramas (to fill the entire width of the viewer with a very specific selection of scenery) but his selection is a wider aspect ratio than my Photosynth viewer on my screen, then since the sides of his selection would float off the sides of my viewer if we were to naively fit the height of his selection to the height of my viewer, we decide to fit the largest dimensions of the selection to the largest dimension of my viewer - namely (but not necessarily - this solution works based on height as well, if the selection were a tall one being viewed on a vertical screen), width.

I suppose that the simplest way to state my wish is simply, 
"Never allow any part of my selection to be pushed outside the viewer when I click on the corresponding highlight thumbnail.".
Jonathan (Over 1 year ago)
Nathanael - the short answer to your issues here is that it's a bug. We don't properly account for the viewer's aspect ration. We're fixing it so that what you include in the highlight is always in view when you click on it.
michaeldenis (Over 1 year ago)
Good exploration of an interesting topic, Nathanael.  You got me thinking of the nature and utility of highlights.  I was thinking, it would be great to change the highlights based on the area of the synth one views.  The view of them could change, say, (making the PSviewer show highlights horizontally for landscape shots and vertically for portrait shots) but also the actual highlights could change to reflect the area of the synth a viewer visits, or the object upon which one views.  Mmanual organization of highlights is my current method for reaching this end, but, down the line, perhaps a more active method could be established.

I'm glad someone is looking into the thumbnails in detail.  I have been suspicious of their aspect-ratios before and the selection of a Synth thumbnail is an artform that I still try to master.
Nathanael (Over 1 year ago)
Thanks for the response, Jonathan. It's great to know that the above was your intent all along. What is the general consensus on the team as far as non-square selections for highlights/tags going forward?

As an aside, a short answer from anyone on the team always goes a long way. It's always encouraging to have someone acknowledge that you guys have heard what's said on the forum and given real thought to what's been said. 

I feel like that especially goes for the Bugs forum. Simply acknowledging that an issue is a real bug and that it's being looked at even if a fix has no imminent release date really does tip the scales between users feeling completely ignored on the one hand or, on the other hand, remaining unhappy with the bug yet being pleased that someone is aware of the problem and plans to do something about it whenever time permits.

Thanks for finding time around all the development responsibilities for answering when you can. It is much appreciated.
aridolan (Over 1 year ago)
I think the most important suggestion offered by Nathanael is to allow editing a highlight after it has been defined. If this is not possible, than at least:
"Never allow any part of my selection to be pushed outside the viewer when I click on the corresponding highlight thumbnail."

The highlights are especially valuable in pano synth, since they can define a programmable animation path. However, in this role their predictability is even more important, since in this case the user is not there to fine-tune the viewport.
TonyErnst (Over 1 year ago)
We have fix in the works that will address the main issue of the selected area of the highlight not always being visible.  Beyond this we have additional plans to make highlights even better.  Stay tuned
TonyErnst (Over 1 year ago)
All - We've fixed the highlight issue in panos.  All of the highlight should now be visible in the viewer when you click on it.  Note that this is retroactive, so you dont have to redo your highlights.  It's also worth noting that one effect of this is that highlights on synths are now not as tight on the selected area as they were prior to today's release.  We're going to continue tweaking, but near term we thought this was the best compromise.
Nathanael (Over 1 year ago)
Thanks, Tony. I'll look forward to your collective continued tweaking for synth highlights, but this is an excellent stop-gap solution for panos.

I have to say that I continue to pull for arbitrarily proportioned rectangular highlights, rather than only squares (although a simple way to draw a square should remain - perhaps holding [Shift] while dragging the selection boundary), but I'm sure that your plans for highlights exceed this 'simple' request.