Beautiful landscapes are prettier than portraits

[WizardStan]

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

The 2858 actually. It's their latest one supporting up to 2560*1600, but only up to 1280x720 for rotation.Here and here.

 

[WizardStan]

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

It also doesn't mention rotation or even scaling. The 2828 looks to be just a bridge, parallel RGB in - MIPI out. I think?
edit: Here's the sales brochure for the 2825/2828, and the 2848. The 2825/2828 describe a 24bit RGB to MIPI interface, the 2848 (which I guess is the pre-cursor to the 2858) is the DSI->DSI with scaling and rotation. It also doesn't mention compression, but it's a sales brochure so probably wouldn't mention it anyway. I'll try to find the 2848 datasheet as well.

 

[EvilDragon]

I've got the 2848 datasheet. It's a simplet versionm than the 2858, it doesn't support scaling as well.

 

[bzar]

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.

 

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

I was replying to you

It also doesn't mention rotation or even scaling. The 2828 looks to be just a bridge, parallel RGB in - MIPI out. I think?

edit: Here's the sales brochure for the 2825/2828, and the 2848. The 2825/2828 describe a 24bit RGB to MIPI interface, the 2848 (which I guess is the pre-cursor to the 2858) is the DSI->DSI with scaling and rotation. It also doesn't mention compression, but it's a sales brochure so probably wouldn't mention it anyway. I'll try to find the 2848 datasheet as well.

Whoops, I thought _wb_ had looked into this before

 

[_wb_]

Ugh, too many 4-digit numbers that look too similar, I get confused.

Anyway, is there one of them that can do lossless rotation at the resolution we need?

 

[Granitehead]

Ugh, too many 4-digit numbers that look too similar, I get confused.

Anyway, is there one of them that can do lossless rotation at the resolution we need?

I think someone said not from the same manufacturer.

 

[WizardStan]

Anyway, is there one of them that can do lossless rotation at the resolution we need?

Considering that we don't know anything about the compression used in the 2858 we can't say that it doesn't. Obviously there's going to be some cases where loss is going to happen, it's a "law of thermodynamics" of computing, but we don't know whether that loss will occur in situations we care about.

 

[EvilDragon]

Ugh, too many 4-digit numbers that look too similar, I get confused.

Anyway, is there one of them that can do lossless rotation at the resolution we need?

No, of course not, otherwise I would've ordered that one...

 

[_wb_]

Ugh, too many 4-digit numbers that look too similar, I get confused.


Anyway, is there one of them that can do lossless rotation at the resolution we need?

No, of course not, otherwise I would've ordered that one...

Could be that it was too expensive or power-hungry or something...

 

[Exophase]

Could be that it was too expensive or power-hungry or something...

You would need over 5MB of on-chip RAM for that, kind of a lot for this sort of application.

WizardStan, I was looking through SSL's patents again and I couldn't find more than that one I linked earlier, and in that one I can't find anything that would suggest more than the ability to perform a straightforward codebook-based vector quantization. Can you show me where you've seen more than that?

 

[WizardStan]

WizardStan, I was looking through SSL's patents again and I couldn't find more than that one I linked earlier

The've got three that all seem to be more or less identical, different in some ways but nothing that makes each stand out as something unique: http://www.freshpatents.com/-dt20140109ptan20140010445.php, http://www.freshpatents.com/-dt20111006ptan20110243437.php, and http://www.freshpatents.com/-dt20100429ptan20100104207.php Reading them over again, I'm wondering what I was thinking the first time I read through them though. Doesn't seem like it really would provide that high of compression as it is in most cases.

 

[Hồng Thất Công]

"Just use the Pandora IPS display for Pyra.  It's been Two MonthsTM," Craig said.

Actually I like the Pandora display.  The first time I booted up I couldn't believe how good it was running full xfce desktop.

So I kind of agree with Craig here.  Let's use Pandora display and move on to next step.  

 

[TrashyMG]

So I kind of agree with Craig here.  Let's use Pandora display and move on to next step.  

They're practically out of stock and hard to come by, Also quoting Craig doesn't make anything correct. 

 

[rohezal]

Can the rotation chip be replaced with a non compressing one? Without much hassle, when the prototype is ready and before mass production begins?

 

[Exophase]

So I kind of agree with Craig here.  Let's use Pandora display and move on to next step.

They're practically out of stock and hard to come by, Also quoting Craig doesn't make anything correct.

Did Craig really say this anyway? He was a huge supporter of using a 1080p screen.

 

[EvilDragon]

Well, Solomon Systech sent me a link where I can test the compression online (it's not public), and WOW - I'm impressed!

Here are a few examples I tried:

http://evildragon.openpandora.org/CompressorTest.zip

In this archive you'll find various BMPs I used for testing.

The 2X0 images are the compressed results.

Basically, the compression is only REALLY visible on the hardcore test - which is unlikely to ever happen, if you ask me (unless you have a coder that wants to trigger epilectic effects...)

Looks pretty good for me!

 

[PokeParadox]

Wow... that's eased my concerns!

 

[Rockthesmurf]

Visually, as expected, it looks pretty decent. If you take the Skyrim images; and look at the difference, there are some pixels which are wrong by RGB( 15, 14, 19 ), where the original pixel is RGB(240, 218, 95), and the compressed version is RGB(255, 204, 76), meaning that the amount wrong for each channel is R: 6.25% G: 6.42% B: 20%, I didn't go out of my way to find the worst possible pixel, just grabbed one which had a reasonable delta (the same delta applied to a source pixel of (1,1,1) would be way more noticeable, as the inaccuracy would be 1500%, 1400%, 1900%, although I doubt you'd get that case).

For me, the compression isn't a problem, particularly given the screen size, but certainly in (small) places, there are (somewhat) sizeable differences.

There must be tools out there that can just take too images and provide a decent metric of how good/bad the compression is that someone might want to investigate.

 

[TrashyMG]

Visually I couldn't see much of a difference even on the hardcore tests. I'm sure some may be more sensitive to it.

 

[EvilDragon]

Yes, the colors are a bit different when they are too detailed - as it needs to compress somehow.

However, colors are different anyways with each LCD anyways, and the Solomon Systech chip can even do color correction, so they can be adjusted to be very different but great for the custom user as well

Visually I couldn't see much of a difference even on the hardcore tests. I'm sure some may be more sensitive to it.

Check the lower text in the hardcore-BMP