DPtoLP gives erroneous results
in [MFC]
|
Prev: FREE Tutorials on HTML XHTML CSS JavaScript XML XSL ASP SQL ADO VBScript, SAP - ABAP
Next: Get BItmap From HDC
From: Joseph M. Newcomer on 26 May 2008 04:03 DPtoLP does not work as specified. When using GM_ADVANCED and a scaling factor, DPtoLP returns erroneous data. There are some severe roundoff errors in the implementation which render it essentially unusable. There is a *different* set of roundoff errors if the scaling is done by SetWindowExt/SetViewportExt. In all cases, the window origin is (0,0). I spent a couple hours looking for bugs in my logic before I just ran a for-loop and got the computations. They are summarized in http://www.flounder.com/msdn_documentation_errors_and_omissions.htm#DPtoLP I suggest caution when using this function. What amazes me is how often I've depended on it in the past! In this case, I want to place the mouse over a magnified pixel and see what the color is by fetching the pixel at the DPtoLP coordinate. Except it didn't work! joe Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Alexander Grigoriev on 26 May 2008 11:23 The problem with that is that in case of non-trivial scaling there may not be a reliable way back to LP. The world transform gives you DP from LP, but it may not be possible to reliably calculate the inverse transform, precisely because of rounding errors. I suppose you don't use complex world transform, because in that case it gets even worse. "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:ihpk34937vs4aua0qcpqrrpdgs60f718t5(a)4ax.com... > DPtoLP does not work as specified. > > When using GM_ADVANCED and a scaling factor, DPtoLP returns erroneous > data. There are > some severe roundoff errors in the implementation which render it > essentially unusable. > There is a *different* set of roundoff errors if the scaling is done by > SetWindowExt/SetViewportExt. In all cases, the window origin is (0,0). > > I spent a couple hours looking for bugs in my logic before I just ran a > for-loop and got > the computations. They are summarized in > > http://www.flounder.com/msdn_documentation_errors_and_omissions.htm#DPtoLP > > I suggest caution when using this function. What amazes me is how often > I've depended on > it in the past! In this case, I want to place the mouse over a magnified > pixel and see > what the color is by fetching the pixel at the DPtoLP coordinate. Except > it didn't work! > joe > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 26 May 2008 20:57 I have a single pixel in the image. On the display, it is a 20x20 square. There can be NO ambiguity as to what the LP is, given any of 400 pixels represent it. Therefore, it is ALWAYS reliable to convert down. It's different if the scaling would place several logical pixels on the same DP, that is, a scaling of < 1.0. But when the scaling is 20.0, there is no question of being about to compute it PRECISELY. It doesn't work with SetWindowExt/SetViewportExt either, but the errors are *different*, and there is also no possible ambiguity. Note that I'm using integer multiples, e.g., 100%, 200%, 300%, ...2000%, not 150% (which could introduce ambiguities because on LP could be 1.5 DPs, meaning it would be ambiguous). The proof of this is that I can write my own code that does it correctly just by dividing the pixel coordinate by 20 (in 20x magnification). So ultimately, the API simply doesn't work in situations where it has no excuse to NOT work. No partial pixels, no many-to-one mappings LP-to-DP and no ambiguity between a DP and its matching LP. The mapping is at worst 1:1 DP-to-LP and otherwise it is many-to-1 DP-to-LP. That's what is annoying. joe On Mon, 26 May 2008 08:23:30 -0700, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: >The problem with that is that in case of non-trivial scaling there may not >be a reliable way back to LP. The world transform gives you DP from LP, but >it may not be possible to reliably calculate the inverse transform, >precisely because of rounding errors. I suppose you don't use complex world >transform, because in that case it gets even worse. > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:ihpk34937vs4aua0qcpqrrpdgs60f718t5(a)4ax.com... >> DPtoLP does not work as specified. >> >> When using GM_ADVANCED and a scaling factor, DPtoLP returns erroneous >> data. There are >> some severe roundoff errors in the implementation which render it >> essentially unusable. >> There is a *different* set of roundoff errors if the scaling is done by >> SetWindowExt/SetViewportExt. In all cases, the window origin is (0,0). >> >> I spent a couple hours looking for bugs in my logic before I just ran a >> for-loop and got >> the computations. They are summarized in >> >> http://www.flounder.com/msdn_documentation_errors_and_omissions.htm#DPtoLP >> >> I suggest caution when using this function. What amazes me is how often >> I've depended on >> it in the past! In this case, I want to place the mouse over a magnified >> pixel and see >> what the color is by fetching the pixel at the DPtoLP coordinate. Except >> it didn't work! >> joe >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Alexander Grigoriev on 26 May 2008 21:27
I never trusted any non-MM_TEXT modes... Always preferred to do the mapping myself. Originally because Win9x could not support >16 bit coordinates. "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:aomm341sp1st0vear9h24dc8dc3v6h1sou(a)4ax.com... >I have a single pixel in the image. On the display, it is a 20x20 square. >There can be > NO ambiguity as to what the LP is, given any of 400 pixels represent it. > Therefore, it is > ALWAYS reliable to convert down. It's different if the scaling would > place several > logical pixels on the same DP, that is, a scaling of < 1.0. But when the > scaling is 20.0, > there is no question of being about to compute it PRECISELY. > > It doesn't work with SetWindowExt/SetViewportExt either, but the errors > are *different*, > and there is also no possible ambiguity. Note that I'm using integer > multiples, e.g., > 100%, 200%, 300%, ...2000%, not 150% (which could introduce ambiguities > because on LP > could be 1.5 DPs, meaning it would be ambiguous). The proof of this is > that I can write > my own code that does it correctly just by dividing the pixel coordinate > by 20 (in 20x > magnification). > > So ultimately, the API simply doesn't work in situations where it has no > excuse to NOT > work. No partial pixels, no many-to-one mappings LP-to-DP and no > ambiguity between a DP > and its matching LP. The mapping is at worst 1:1 DP-to-LP and otherwise > it is many-to-1 > DP-to-LP. That's what is annoying. > joe > > On Mon, 26 May 2008 08:23:30 -0700, "Alexander Grigoriev" > <alegr(a)earthlink.net> wrote: > >>The problem with that is that in case of non-trivial scaling there may not >>be a reliable way back to LP. The world transform gives you DP from LP, >>but >>it may not be possible to reliably calculate the inverse transform, >>precisely because of rounding errors. I suppose you don't use complex >>world >>transform, because in that case it gets even worse. >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >>news:ihpk34937vs4aua0qcpqrrpdgs60f718t5(a)4ax.com... >>> DPtoLP does not work as specified. >>> >>> When using GM_ADVANCED and a scaling factor, DPtoLP returns erroneous >>> data. There are >>> some severe roundoff errors in the implementation which render it >>> essentially unusable. >>> There is a *different* set of roundoff errors if the scaling is done by >>> SetWindowExt/SetViewportExt. In all cases, the window origin is (0,0). >>> >>> I spent a couple hours looking for bugs in my logic before I just ran a >>> for-loop and got >>> the computations. They are summarized in >>> >>> http://www.flounder.com/msdn_documentation_errors_and_omissions.htm#DPtoLP >>> >>> I suggest caution when using this function. What amazes me is how often >>> I've depended on >>> it in the past! In this case, I want to place the mouse over a >>> magnified >>> pixel and see >>> what the color is by fetching the pixel at the DPtoLP coordinate. >>> Except >>> it didn't work! >>> joe >>> Joseph M. Newcomer [MVP] >>> email: newcomer(a)flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |