I have bought this up before but I feel like it is time to bump it, also curious what anyone else thinks.
I think it would be much more sensible for Isadoras values to be pixel based, or at least have that option rather than the percentage.
For cropping trimming, moving, and any locations giving pixel coordinates would be much more handy. Most of all in the mapper.
A common scenario is getting a video with several parts that need to be mapped. In the design process we can define where the source slices are, if we could enter pixel coordinates for the source quads we could just type them in. As it should now it is a lot of zooming and nudging and hoping you are in the right spot. Same for output would be great, it would be easy to make a pixel for pixel source to output quad pair and then tweak the output quad to match reality.
I understand that this is confusing with media of different sizes, but in any pro production this does not happen. All files are prepared at the correct resolution (so maybe this calls for two modes), however i think this is also simplified by the scale to smallest, largest, default resolution option in the preference.
Where this gets really great is in blends, if we knew the pixel width of a blend and could enter the correct pixel coordinates in the mapper then we could very quickly set source and destination points for quads that go over the blend. They may not end up perfect due to rotated projectors, but then adjustment would be a fast task.
To be geaky about it a 0,0 position of an image with the same size as the stage would have it fill the stage exactly, -ve values would move the image left and positive to the right, from that 0,0 anchor point.
Is this only me?
I see a case for both.
In many cases, percentages are faster and more scaleable.
The only time I convert is if I am doing something generative (calculated in another coordinate system), then converting between square units and non-square percentage units can be a little confusing.
I find there are many situations where my stage sizes may be forced to change venue to venue. The percentage system makes this much easier.
Pixels are more precise perhaps, and in the very least more inline with how things are represented in most graphics softwares.
Mark introduced me to a trick sometime back for placing an image on the stage at its pixel size. (dynamically setting the scale of a projector based on the images size and stages size)
I now use this method all over. I suspect a few user actors could be made to help simplify the use of pixels in Isadora.
Yes i can understand the percentage part especially with mixed resolutions and changing stage sizes, although again i think this is solved by the default resolution setting, in essence it should just scale up or down on output after the projector actor. In the end i don't see another way of getting precision, especially in the mapper without pixel coordinates. So if there is an argument for both i would love both, if there was a key command to start Isadora in pixel coordinate mode i would do it every time.
Maybe you can share the precision method?
It's an interesting topic actually, as it highlights Isadora's presence in both the "art" and "media server" world – to give those two areas less than adequate names. The same distinction applies to Time Code vs. Percentages for the loop points.
That said, the thing that's a little difficult is the User Interface aspect. For video output, each actor will have to have a way to access the current size of the stage. That's not such a bummer, except that the size of the stage changes when you go from full resolution output to the preview. Then what? And what if you're previewing your material on the laptop screen (1440 x 900) and then switch it to a real output (1920x1080)? Do you always read the absolute numbers? The values specified for the laptop screen will not be the same as when you're checking it out on the laptop main screen.
Same thing with the movies: each time you change movies, the Movie Player will need to know the frame rate of the movie (24, 25, 29.97, 30) of the movie so that it can correctly interpret the timecode input, because the number of frames represented for 00:01:00:00 isn't the same for 30 drop frame (29.97) and 30
I have it in my head though Fred. I'll see what we can do.
@mark i definitely see the complications, one solution would be a stage resolution setting Vs a stage output size, where your stage resolution is set Vs stage output size which is the actual output. It follows the logic of the default processing size, and would be scaled at the last moment (i would be willing to pass to a virtual stage to counter this, although my resolutions are fixed early on in projects) . Actually the default processing resolution parameter could logically propogate all the way to the stage irrelevant of the connection. One problem in linking these is large movie sizes that span multiple screens.
Process aside, irrelevant of Isadora as an artistic tool Vs media server i have always missed being able to be precise with the coordinates.
One example where the current system falls re flexibility to plug into any resolution beamer and have the coordinates stay fixed is if the aspect ratio changes. If you design on a 1280*720 screen and plug into a 1280*800 beamer (common resolutions and many screens in 16:9 will not give you access to non stretched 16:10 output- easy mistake for a beginner with good knowledge and intentions and workflow) the coordinates will all be off vertically due to the change in aspect ratio.
Having said that for the mapper and for the blend this would be really great, and take away a lot of guess work in setting up.
I think the Timecode Vs percent is a little easier to solve with current actors, it is easy to make a few user actors of modified movie players that do this. The coordinate system means a user actor for every video processing module with coordinate options.
I see it is a lot of work, but as Isadora knows the sizes of the movies and images it is playing and it knows the resolution you chose to work at this could be solved.
As much as i would love to see this i understand there is a current list of priorities, having had some amazing results with recent betas i don't want to interrupt your flow. It would however go more to the pro media server features (Izzy is starting to stand up very well).
Would you be willing to share the specifics around the trick for dynamically setting the scale of a Projector based on the image size and stage size, or is it a trade secret?
Heres the guts of it.
- Get the pixel size of the stage, and the image
- calculate the Percentage of the stage size for the orientation (here I calculate both for a landscape and portrait)
- select the value to output based on orientation. (center comparator)
I guess, this could be make a slight bit more efficient using a router, so that only one set of calculations are made.
I've been using this exact actor for the past 3 years.. (note: probably haven't tested portrait vs landscape very well)
user actor: DX graphicPlacer-ZoomCalc.iua