INTERACT FORUM
Devices => Video Cards, Monitors, Televisions, and Projectors => Topic started by: Movieman on June 14, 2020, 09:27:19 am
-
First my custom resource file:
<!--
Media Center Resource XML (Default / English)
-->
<MJRS version="1.0">
<!--
MadVR Anamorphic lens correction = 13/9
-->
<ACCELERATORS>
<!-- Playback engine Zoom custom shortcuts (shared) -->
<Entry Key="Alt;A" Command="28038" Param="100" /> <!-- 1.77:1 -->
<Entry Key="Alt;S" Command="28038" Param="96" /> <!-- 1.85:1 -->
<Entry Key="Alt;D" Command="28038" Param="86" /> <!-- 2.00:1 -->
<Entry Key="Alt;G" Command="28038" Param="79" /> <!-- 2.20:1 -->
<Entry Key="Alt;H" Command="28038" Param="74" /> <!-- 2.40:1 -->
<Entry Key="Alt;J" Command="28038" Param="69" /> <!-- 2.55:1 -->
<Entry Key="Alt;K" Command="28038" Param="64" /> <!-- 2.76:1 -->
<Entry Key="Alt;L" Command="28038" Param="59" /> <!-- 2.85:1 -->
</ACCELERATORS>
</MJRS>
Could you possibly consider enhancing the handling of the zoom preset parameter?
1. The Parameter actually decreases in value as the zoom increases and the value seems to have no relation to actual zoom percentage shown on the GUI when the i / o zoom option is used
2. The parameter is required to be an integer, which does not allow for sufficient granularity in the sizing of the image.
In other words, using a parameter of 74 produces an excessive zoom amount for a 2.40:1 image cutting off part of the image area, while 75 leaves visible black bars
3. For some obscure reason, a value of 80 doesn't seem to give a valid zoom. (Not sure about this one as I haven't tested it recently.)
So, while the function is there, it certainly could do with some enhancements.
For now, I am certainly happy to have the capability, but I almost always have to use the i / o keys to fine tune the image size to establish the exact zoom amount to completely eliminate the black bars without eliminating an excessive amount of the image.
Thanks in advance for any consideration.
-
I am using this as a reference for sizing, rather than depending on individual titles which may not be exact.
-
Bump, please.
Am i making an invalid assumption that the 28038 command for the video engine zoom is a part of JRiver Media Center?
If it is, I would appreciate an acknowledgement on whether or not anything can be done to improve this function per my above request.
Should I have posted it on a different section of the forum?
Thanks, Vern
-
That looks like MC command.
I recall you had some discussion about this, but I dont remember what it was about ... are you trying to use anamorphic lens? ... or is there another reason why you zooming in? (sorry I cannot truly remember your set up)
-
Yes, anamorphic lens + Constant image height 2:65:1 screen. Zoom is working for me and using MadVR to set the proper anamorphic lens correction is working fine.
The I/O keyboard function is working fine. The problem comes when trying to assign a zoom value using, for example:
<Entry Key="Alt;H" Command="28038" Param="74" /> <!-- 2.40:1 -->
A value of 74 for the parameter results in too much zoom, a value of 75 results in too little zoom. Since the parameter only accepts an integer, it is impossible to set zoom accurately using using the command.
The 28038 parameter field would need to be changed to accept a decimal value like 73.67.
Using the I/O hot keys on the keyboard allows me to accurately zoom after the fact, but I really prefer that the presets deliver the same granularity as the I/O function does.
Also, from a purely logical point of view, why does a decrease in the parameter from 100 at no zoom to 74 represent an increased zoom. I can live with that, it just seems counter-intuitive.
Let me know if you need any more info.
Thanks....
-
I am not expert on this at all ... but does not MadVR support this automatically by detecting blackbars (and removing them) ... I vaguely recall seeing this on one of the forums (from what i remember the setting for this was all over the place in MadVR)
EDIT: found that forum ... http://forum.doom9.org/showthread.php?t=173286
-
Yes it will, but it does so with a delay. It also doesn't handle situations like a 1.66:1 blu ray that it actually an open matte presentation of a film that was projected theatrically at 1.85:1.
Just for reference, JRiver is the only player I have used with this issue.
Other players (Zoom Player, MPC-BE, MPC-HC, and VLC) all allow zoom presets to be defined with 2 decimal place accuracy.
-
We can't really change how these values work since anyone that uses them might otherwise suddenly have their values broken.
They are not meant to match the percentages shown in the UI, since the percentages depend on the video resolution and the window size or screen resolution. These values do not. This is the internal representation of the zoom value as we would also save it into the [Playback Info] field when changed manually - with the same precision, too. This is basically a two digit decimal value multiplied by 100 (so it has two digit decimal precision).
This internal representation may not be very intuitive, but you can change the zoom with the +/- keys during playback, stop playback, and read it out of the [Playback Info] field.
The 1% steps with the keys are definitely bigger then 1 pixel movements, so achieving a pixel accurate zoom at any arbitrary value is not quite the goal for any of these.
-
Here's what I see
First of all the I/O zoom steps are perfectly acceptable in terms of accuracy. So that piece of the puzzle is working fine.
However:
101% zoom = 2.99
102% zoom = 2.98
103% zoom = 2.98
104% zoom = 2.97
105% zoom = 2.96
So, I still maintain the presets do not offer the same granularity as provided by the zoom in and out (I/O) keys as shown by both 102% and 103% zoom being represented by the 2.98 value.
Methinks that a gremlin exists somewhere in there relating to the precision of a variable.
-
101% zoom = 2.99
102% zoom = 2.98
103% zoom = 2.98
104% zoom = 2.97
105% zoom = 2.96
So lets take this one more step:
I play a video and set the the zoom to 103% using the I key. The resulting value saved in the Playback Info field is 2.98.
Then a week later I play the same video, and the playback engine reads the 2.98 from the playback field.
Now how will it know how to translate the 2.98 to a 103% zoom when that same 2.98 also applies to a 102% zoom? I suspect it won't and the resulting playback will be at an incorrect 102% zoom.
This is exactly the same behavior that occurs when setting the 28038 parameter with a hot key.
This is clearly a bug in JRiver, although it is not actually with the 28038 parameter code, and it does need to be addressed.
Thanks again.
-
so ... using "I" key works? ... maybe automate around that in combination with Playback Info field and command 28038 ... for example use 28038 to closest known good value then send predetermined number of "I" keystrokes to MC to fine tune.
I know its not an elegant solution but at least it might work
I suspect it won't and the resulting playback will be at an incorrect 102% zoom.
also its always better to confirm a problem rather speculate over it. Speculation wont get much attention.
-
I know its not an elegant solution but at least it might work
I'm not looking for something that "might work". GIGO (garbage in garbage out) means that you can't create a solution when the input data is possibly invalid.
I have been a JRiver user since version 19 and have always paid for my upgrades.
I'm looking for an acknowledgement that this is a bug in the zoom implementation, which it clearly is when at least two different zoom values 102% and 103% store the same value in the playback info data.
I'm sure this same behavior exists for many other zoom values as well, and is affecting the consistency of zoom when a title that has been played is replayed, since it depends on the playback info data which has been generated (incorrectly) previously.
It seems to me that I have invested a fair share of effort debugging this issue and providing data to explain why it's happening. Since JRiver is a paid software product, it also seems reasonable to me that JRiver acknowledges that it is a bug and fixes it.
Thanks in advance, hoping to see a fix soon . :(
-
Now hoping for any response at all from the developers ?
Has anyone actually looked at the code to see why at least two different zoom values (102% and 103%) actually do store the same value in the playback info data?
It seems to me that this issue is affecting anyone who uses the zoom function I and O keys and expects JRiver to always use the exact same zoom percentage value for any subsequent viewing of the same media, not just those like myself who are depending on the accuracy of the zoom presets.
-
Now hoping for any response at all from the developers ?
Hendrik, who is one of JRiver's developers, already responded above.
-
Hendrik, who is one of JRiver's developers, already responded above.
That's not actually a response to the latest discovery of what is actually broken. It's a response to my earlier questions.
This: Has anyone actually looked at the code to see why at least two different zoom values (102% and 103%) actually do store the same internal representation value in the playback info data? is a flat out bug in the code. Having two different zoom percentages create the same internal representation zoom value in the database playback info field is just flat out broken, and has nothing to do with what an existing user may have come to expect.
And it's not just 102% and 103% that exhibit this behavior, either. It occurs throughout the zoom range.