How to get rotation working

[_wb_]

$ 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]

@_wb_, what information can I gleam off those numbers? Is that good or bad?

 

[ImmaculateChimp]

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]

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.

 

[WizardStan]

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.

 

[levi]

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.

 

[Exophase]

@_wb_, what information can I gleam off those numbers? Is that good or bad?

Just means that the images don't have a large part shifted over, which would result in much bigger rms errors.

 

[ImmaculateChimp]

...hmm, perhaps my brain is the problem... h34r: 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]

...hmm, perhaps my brain is the problem... h34r: 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]

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.

 

[ImmaculateChimp]

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..

 

[_wb_]

@_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.

 

[captainhorst]

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.

 

[WizardStan]

Actually I was hoping for a clear yes/no answer

Oh, sorry. Yes, it can be bypassed. That was the very first thing EvilDragon demonstrated with it because it took a while to get the rotation activated.

 

[captainhorst]

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]

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]

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.

 

[TrashyMG]

Well I did say guess...

 

[WizardStan]

And a very reasonable guess it was.

 

[captainhorst]

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.