How to get rotation working


_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,390
Age
41
Location
Brussels, Belgium
Code:
$ compare -metric rmse hardcore.bmp hardcore_2X0.bmp d.pnm
522.842 (0.00797805)
$ compare -metric rmse gradient.bmp gradient_2X0.bmp d.pnm
137.65 (0.0021004)
$ compare -metric rmse gta5_2X0.bmp gta5.bmp d.pnm
615.399 (0.00939039)
$ compare -metric rmse Knytt_Underground_2X0.bmp Knytt_Underground.bmp d.pnm
197.037 (0.00300659)
$ compare -metric rmse slashdot_2X0.bmp slashdot.bmp d.pnm
56.0229 (0.000854855)
$ convert hardcore.bmp -quality 93 hardcore.jpg
$ compare -metric rmse hardcore.bmp hardcore.jpg d.pnm
538.318 (0.0082142)
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,345
@_wb_, what information can I gleam off those numbers? Is that good or bad?
 
Last edited by a moderator:
Joined
Sep 22, 2009
Messages
235
Location
carmel, indiana - united states
sorry, my mistake.. the ones NOT labeled with 2X0 have a missing vertical column in the center (or maybe the 2X0's have extras). On my pc, at least, all 2X0's are slightly wider, left-to right. probably the easiest one to spot is the GTA4 one, Niko's left foot looks wider on the 2X0-version..
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,345
sorry, my mistake.. the ones NOT labeled with 2X0 have a missing vertical column in the center (or maybe the 2X0's have extras). On my pc, at least, all 2X0's are slightly wider, left-to right. probably the easiest one to spot is the GTA4 one, Niko's left foot looks wider on the 2X0-version..
I don't see it, even on a Macbook pro Retina display.  the ones not labeled are supposed to be the control source images.
 
Last edited by a moderator:

WizardStan

Mega GP Mania
Joined
May 24, 2008
Messages
16,731
sorry, my mistake.. the ones NOT labeled with 2X0 have a missing vertical column in the center (or maybe the 2X0's have extras). On my pc, at least, all 2X0's are slightly wider, left-to right. probably the easiest one to spot is the GTA4 one, Niko's left foot looks wider on the 2X0-version..
The images are identical in resolution: every single one is 1280x720. I don't see any missing or extra columns.edit: to verify I even opened the two GTA images and overlayed them: Niko's feet line up perfectly on my display.
 
Last edited by a moderator:

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
15,852
Location
Somewhere off the coast of the EU
I also loaded them up in Gimp as layers and toggled them on and off - I couldn't spot a pixel differing by eye, and certainly not one half of the image shifting sideways.
 
Joined
Sep 22, 2009
Messages
235
Location
carmel, indiana - united states
...hmm, perhaps my brain is the problem... :ph34r: but, for me, it's there, consistently again and again (even though windows says they are the same resolution, the dpi does differ per pair according to windows "properties" box for each item, though. on some the non-2X0 version will be higher, and on others it's not..)... but if no one else is seeing it, maybe this laptop I'm using is..problematic? at least whatever the heck this is that "seems" to be going on for me shouldn't be occurring on the Pyra..

sorry for bothering everyone.
 

FelixNemis

Very Active Member
Joined
May 15, 2012
Messages
306
...hmm, perhaps my brain is the problem... :ph34r: but, for me, it's there, consistently again and again (even though windows says they are the same resolution, the dpi does differ per pair according to windows "properties" box for each item, though.
Sounds like whatever image viewer you're using is taking the DPI of the image into account and scaling one version.No Idea why the images have different DPI values though (they do for me as well).
 

WizardStan

Mega GP Mania
Joined
May 24, 2008
Messages
16,731
The DPI is just an extra resolution setting in the BMP header, it's a "hint" to the system as to how to print the image correctly. Programs are free to set it to whatever they want and also free to ignore it if they want.

Presumably whatever ImmaculateChimp is using does not ignore the different DPIs. I'd like to know what that is so I know never to use it because that's garbage.
 
Joined
Sep 22, 2009
Messages
235
Location
carmel, indiana - united states
well WizardStan, I'm just using the standard, boilerplate windows xp (yes, OLD laptop) image viewer(you double click on the picture file and you get the image..). regardless of dpi, though, the 2X0 versions are always visually wider, the vertical "line"(it isn't very wide) in them is using the same colors/patterns as everything around it, to the point that I can't tell if it is supposed to be there or not. I wouldn't even know it was there if I didn't have the other version of the picture to compare it to..
 
Last edited by a moderator:

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,390
Age
41
Location
Brussels, Belgium
@_wb_, what information can I gleam off those numbers? Is that good or bad?
Those are root mean square errors, the smaller the number, the better. It gives a rough indication of how lossy the compression is.

The compression is about as lossy (though probably not with the same type of artifacts) as JPEG compression at quality 93 to 100:


$ compare -metric rmse slashdot_2X0.bmp slashdot.bmp d.pnm
56.0229 (0.000854855)
$ convert slashdot.bmp -quality 99 slashdot.jpg
$ compare -metric rmse slashdot.bmp slashdot.jpg d.pnm
71.9065 (0.00109722)
$ convert slashdot.bmp -quality 100 slashdot.jpg
$ compare -metric rmse slashdot.bmp slashdot.jpg d.pnm
54.649 (0.00083389)

$ compare -metric rmse Knytt_Underground_2X0.bmp Knytt_Underground.bmp d.pnm
197.037 (0.00300659)
$ convert Knytt_Underground.bmp -quality 97 Knytt_Underground.jpg
$ compare -metric rmse Knytt_Underground.bmp Knytt_Underground.jpg d.pnm
187.24 (0.00285711)

$ compare -metric rmse gta5_2X0.bmp gta5.bmp d.pnm
615.399 (0.00939039)
$ convert gta5.bmp -quality 93 gta5.jpg
$ compare -metric rmse gta5.bmp gta5.jpg d.pnm
642.761 (0.0098079)
$ convert gta5.bmp -quality 94 gta5.jpg
$ compare -metric rmse gta5.bmp gta5.jpg d.pnm
588.753 (0.00898379)

$ compare -metric rmse gradient.bmp gradient_2X0.bmp d.pnm
137.65 (0.0021004)
$ convert gradient.bmp -quality 100 gradient.jpg
$ compare -metric rmse gradient.bmp gradient.jpg d.pnm
181.246 (0.00276564)

This amount of loss is totally acceptable, especially on a device with a pixel density as high as this. Keep in mind that HDMI output to a big screen would not need to go through the rotation chip.

Still, it's not completely lossless. So if it turns out that we are going to use the Vivante 2D acceleration anyway for something (e.g. compositing an overlay layer), and it turns out that we can get the rotation from it essentially for free (because the extra memory usage and transfers are needed anyway), then we should consider to take that option imo.
 
C

captainhorst

Guest
Can someone please confirm whether it's true that the rotator chip can be disabled or bypassed somehow?
Well, great. Instead of getting an answer to my original question I just get three replies doubting my abilities to notice the compression artifacts. Actually I was hoping for a clear yes/no answer.

I'm not saying the compression is a major issue, just a minor annoyance. It's probably worse just knowing that these artifacts exists.

And yes tearing artifacts are way worse. But I'm confident in Nikolaus' abilities to resolve this issue.

I'm sorry if my tone was a bit harsh. I didn't want to attack the work of anyone involved in this project. I'm just interested in developing for the Pyra at some point and was wondering whether I can avoid the negative effects of the rotation chip (lossy compression, tearing (for now), latency) and have pixel perfect output. For this I would use fullscreen OpenGL anyways and don't need the rotation chip. That's why I asked the question in the first place.

Again sorry to bother again and thank you in advance for taking your time to respond.
 
C

captainhorst

Guest
Oh, that's great news to me. :) So from a developer's perspective will it be as simple as calling a function or how is this bypass achieved?
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,345
Oh, that's great news to me. :) So from a developer's perspective will it be as simple as calling a function or how is this bypass achieved?
My guess control will be on a GPIO that can be enabled/disabled easily enough.
 

WizardStan

Mega GP Mania
Joined
May 24, 2008
Messages
16,731
Not a GPIO, it's a special MIPI code that needs to be sent to enable and disable bypass mode.

Here we go

EvilDragon discusses the troubles of putting the chip into bypass mode in order to send the LCDs initialization string then back into rotation mode. Eventually solved but what a mess.

So in theory all it would take is to add some kind of "bypassMode(bool)" function call in the display driver to send the right codes. Maybe it could be automatic, just a tall resolution that your application can select, and the display driver sends the correct code to turn off rotation.
 
Last edited by a moderator:
C

captainhorst

Guest
Not a GPIO, it's a special MIPI code that needs to be sent to enable and disable bypass mode.

Here we go


EvilDragon discusses the troubles of putting the chip into bypass mode in order to send the LCDs initialization string then back into rotation mode. Eventually solved but what a mess.


So in theory all it would take is to add some kind of "bypassMode(bool)" function call in the display driver to send the right codes. Maybe it could be automatic, just a tall resolution that your application can select, and the display driver sends the correct code to turn off rotation.
Thanks for digging up that link. About automation: I would prefer setting the bypass mode explicitly. I think lots of games enumerate video modes and I think the portrait modes could lead to confusion since not a lot of games support rotation. But maybe not..

Ideally the graphics driver would hide all this. When choosing a fullscreen video mode bypass mode could be enabled and the graphics chip needs to be told to rotate the output by 90° provided the graphics chip has such functionality at no cost. The benefit of this would be that any OpenGL game would just work with this.

But I'm also fine with turning on bypass mode and applying a 90° degree rotation to my projection matrix.

Then there's the case when a game crashes. The bypass mode needs to be enabled again possibly before exiting the video mode.
 
Last edited by a moderator:
Top