Beautiful landscapes are prettier than portraits

[Caine]

While I don't really care about the loss of resolution (1080p seems a bit overkill anyway),

I do worry about the lossy compression and the implied loss of pixel accuracy.

 

[SNESFAN]

So not everything has use this chip right? You can choose to bypass it and use xserv for the rotation for things that use x, or you can always program your apps with rotated graphics in mind. Might be pretty confusing though. Is it possible to build something like this into a SDK/pyra emulator in qemu so newly programmed apps created in that can rotate sprites and surfaces etc when compiling. My problem I had on the shield was that I didn't have the experience or time to go into each and every emulator and app convert all the graphics by hand. Would it be possible to automate this process when compiling or at least make it simpler for people who do not want to use this chip.

 

[Exophase]

I think if there's a reasonable 720x1280 display option it should be evaluated now, and then the discussion can be restarted with that in mind. That changes any bandwidth/CPU/whatever for handling rotation of the entire screen at full resolution by a factor of 2.25.

 

[EvilDragon]

The compression is only needed for 1280x720 rotation, and we don't know yet how much and if it affects the image in any way.

With lower resolutions (up to 960x544, AFAIR), compression is not needed.

So any games with Pandora resolution or lower do not need any compression at all.

 

[Caine]

The compression is only needed for 1280x720 rotation, and we don't know yet how much and if it affects the image in any way.

With lower resolutions (up to 960x544, AFAIR), compression is not needed.

So any games with Pandora resolution or lower do not need any compression at all.

Does this also hold when low resolution source content is scaled (by the chip) to 1280x720 or is the output resolution the determining factor.I.e. should we expect lossy compression in the following pipeline: 960x544 or less --rotation-> --scaling-> 720p.

 

[EvilDragon]

Looked up the datasheet: It's up to 960x600 and the scaler is after the compressor in the block diagram, which means that resolutions up to 960x600 can be scaled without needing compression.

 

[God Ginrai]

The compression is only needed for 1280x720 rotation, and we don't know yet how much and if it affects the image in any way.

With lower resolutions (up to 960x544, AFAIR), compression is not needed.

So any games with Pandora resolution or lower do not need any compression at all.

What's the point of having a high-res screen if I can't even use it to the full extent of its abilities? I want pixel-perfect display at all resolutions the screen is capable of. Otherwise, higher resolution has no meaning.

-God Ginrai

 

[LEOXD]

@God Ginrai: Explain. If some pixels show only approximately what they should be and your eye is unable to detect that they're not showing the correct stuff (which is generally a goal for lossy image compression), why does the higher resolution has no meaning? 

 

[God Ginrai]

@God Ginrai: Explain. If some pixels show only approximately what they should be and your eye is unable to detect that they're not showing the correct stuff (which is generally a goal for lossy image compression), why does the higher resolution has no meaning?

Just because it is a goal does not mean it actually performs well in practice. You have no idea how good this compression is, so you have no idea if it is impossible to discern the difference. Also, many games were specifically designed for the medium that they would be displayed on. This loss of accuracy could make assets for games look worse because it is not using the exact color that the artist originally chose. Graphical fidelity is just as important as audio fidelity.

-God Ginrai

 

[Morn]

why does the higher resolution has no meaning?

Because even if you can't see the difference your OCD knows it's there

You have no idea how good this compression is, so you have no idea if it is impossible to discern the difference.

If the difference is easily discernable ED will look for another solution. That's pretty obvious.

Also, many games were specifically designed for the medium that they would be displayed on.

I don't think there's so many games designed for resolutions bigger than 960x544 which require perfect color fidelity.

 

[God Ginrai]

If the difference is easily discernable ED will look for another solution. That's pretty obvious.

I never said "easily" discernible. Just because one person can't see it doesn't mean another can. I know people who can't tell the difference between FLAC and MP3s aside from file size. That doesn't mean there isn't a difference in quality that some people can discern.

I don't think there's so many games designed for resolutions bigger than 960x544 which require perfect color fidelity.

All there needs to be is one that is capable of running on the Pyra for you to be making the Pyra a bad system for it in that case. Not to mention, many Indie games lately are 2D, and there are some quite detailed ones out there that make use of the higher resolutions of today's computer monitors.

-God Ginrai

 

[Foxgod]

Wll, lets just wait and see what the team thinks about the display, and like mentioned before, is 5.3 inch an option? anything with landscape in that segment? or 5.1?

 

[WizardStan]

1280x720 vs 960x600 only requires a 37% compression; that's actually a very low ratio. They could easily have an algorithm which is lossless in the majority of situations and only becomes a little lossy for very noisy images where you wouldn't notice the loss anyway.

Or maybe they don't, ED's going to try it and find out. There's no point in complaining about something that may not be an issue.

If only there were a way to actually record the output of the chip in digital form. Be easier to make comparisons than just eyeballing it.

 

[God Ginrai]

Or maybe they don't, ED's going to try it and find out. There's no point in complaining about something that may not be an issue.

Hence why I posted this earlier:

Yup. In the mean time, I think the best course of action is looking further into that bottleneck. Contact the developer who worked on the TILER and ask them if there is some faster way to read and write to the TILER from the CPU.

-God Ginrai

 

[Exophase]

1280x720 vs 960x600 only requires a 37% compression; that's actually a very low ratio. They could easily have an algorithm which is lossless in the majority of situations and only becomes a little lossy for very noisy images where you wouldn't notice the loss anyway.

It's a low ratio for compressed image files. But you really can't compare a realtime, fixed size compression algorithm to something that has the luxury of analyzing an entire image and taking a relatively large amount of memory and time to compress.

Compression ratio here is fixed 8:5. An example compression method if it's 24bpp would be to compress a 16 pixel run to an 8 pixel codebook plus 48 bits of indexes.

 

[_wb_]

1280x720 vs 960x600 only requires a 37% compression; that's actually a very low ratio. They could easily have an algorithm which is lossless in the majority of situations and only becomes a little lossy for very noisy images where you wouldn't notice the loss anyway.

It's a low ratio for compressed image files. But you really can't compare a realtime, fixed size compression algorithm to something that has the luxury of analyzing an entire image and taking a relatively large amount of memory and time to compress.


Compression ratio here is fixed 8:5. An example compression method if it's 24bpp would be to compress a 16 pixel run to an 8 pixel codebook plus 48 bits of indexes.

Yes, or just go from RGB888 to RGB555. I hope it's something smarter than that though.

This quote makes sound like they could even be using only the 4 most significant bits per channel

Another information:

Select the following compression algorithm.:


Write (48 bits to 24 bits) : write MSB of the pixels: B[23:20],B[15:12],B[7:4], into the RAM

 

[_wb_]

Solomon Systech MIPI Master Bridge Chips SSD2805/SSD2825/SSD2828 support high-speed, low-power displays in application-rich mobile devices.

[SIZE=9pt]SSD2828 is able to support display resolution of up to WUXGA (1920x1200), while SSD2825 and SSD2805 are able to support display resolutions of up to WXGA (1280x800) and WVGA (480x854) respectively.[/SIZE] All ICs adopt the physical layer of low voltage differential signaling as defined by MIPI specifications.

Maybe we should use the SSD2828 instead of the SSD2825? I don't know the details, but if SSD2825 cannot do lossless rotation of 720x1280 to 1280x720, then most likely SSD2828 can.

 

[bzar]

SSD2828 datasheet doesn't actually have a single mention of using compression for any resolution. Am I looking in the wrong place?

EDIT: Also, I'm by no means qualified to analyze the power characteristics, but it seems the power consumption is measured in high speed mode to be max 1.2V * (75.6 + 0.53 + 0.75)mA = 92.256mW? Also in ultra-low power state it'd be max 1.2V * (150 + 285 + 150)µA = 702µW?  (numbers from recommended operating conditions and DC characteristics chapters)

These don't sound too bad compared to what the other parts consume.

(please correct me if I didn't take stuff into account)

 

[_wb_]

SSD2828 datasheet doesn't actually have a single mention of using compression for any resolution. Am I looking in the wrong place?

Yes, you're looking at the wrong datasheet: SSD2825 is the one ED was talking about.

EDIT: Also, I'm by no means qualified to analyze the power characteristics, but it seems the power consumption is measured in high speed mode to be max 1.2V * (75.6 + 0.53 + 0.75)mA = 92.256mW? Also in ultra-low power state it'd be max 1.2V * (150 + 285 + 150)µA = 702µW?  (numbers from recommended operating conditions and DC characteristics chapters)


These don't sound too bad compared to what the other parts consume.


(please correct me if I didn't take stuff into account)

Well, my Pandora consumes ~600mW total with the screen at lowest brightness, so adding 92mW to that is not the end of the world, but it's not insignificant either.

 

[comradekingu]

It would be really nice if 1280x720 could be done losslessly. Otherwise you end up with non-good pixelmapping, unless you go down to 640x360  and thats too little.

If 1280x720 isnt lossless there isnt a lesser option thats also good enough. For some things sure, but not on the whole.

With the 1080x1920 you get 540x660, i dont know if it could be the other way with the scaler, but still.

Can the scaler part be easily replaced?