Anyone?

I coulnd't venture a guess since I have really no idea where Lumagen is with the Radiance but I'm eager as hell to see one in action. With the Vantage reports as positive as they are I'm thinking the Radiance will be the end all.

Maybe Jim P. will chime in with more info, but last time I spoke to the company (approx. 2 weeks ago) nothing had changed. Still saying 3d/4th quarter. Can't blame them for not being more specific considering the heat thrown at Calibre and PM (Crystalio) for announcing, and then failing to meet the dates given.

Jim

I want 6 or 8 HDMI... I suppose the Radiance will handle this..

I hope Lumagen Radiance to use two Realta chips.

HQV VPs with one Realta chips can not get advantage of full of HQV performance.
For example, One Realta chip can not process the CNR and aka "Edge Adaptive algirithm" at the same time.

It seems that Lumagen is deliberating this point:
- one Realta with poor performance
- or two Realta with good performance.
But his somewhat high MSRP(~$6000) make me expect two Realta chips.

Jeff,
I believe the Radiance is planned to have 10 video inputs, 6 of which are supposed to be HDMI. (and 2 HDMI out).

End of 2006... maybe.

Does anybody have a list of Vantage processors available now and in the next year and their possible prices, features, etc. ?

Does anybody have a list of Vantage processors available now and in the next year and their possible prices, features, etc. ?

There's a list here:-

http://www.hqv.com/products.cfm

That list is incomplete, out of date, and inaccurate. Otherwise, it is fine. :)

And Bill. Vantage is a processor using the Realta chip. I assume your question is there a list of processors using the Realta chip?

That list is incomplete, out of date, and inaccurate. Otherwise, it is fine. :)

Great. :rolleyes:

For example, One Realta chip can not process the CNR and aka "Edge Adaptive algirithm" at the same time.

This is not true. One Realta can run the CNR algorithm as well as an "Edge Adaptive/Diagonal Edge detection" algorithm.

Mark, that list is pretty accurate it seems to me (although the Cinetron projector is not on there I notice - I'll get that updated). Is there something you notice is incorrect or missing there?

Thanks,

Andy K.
ASIC Design Engineer
Silicon Optix Inc.

Yes. How about the Algolith Dragonfly, for example? And the Lumagen Radiance is now supposedly slated for sometime in the second half of 06 after Jim Peterson practically bit my head off when I posted there was zero chance IMNSHO that Lumagen would have it out by the 2Q. And I love the Lumagen products and company, don't get me wrong.

THe above link staes the Radiance will be available 2nd Q of 2006....(or any day now) ;)

(No it really does say that)

I know it says that BUT the Lumagen site under news says the Radiance will be available 2H 2006 (that means sometime between July 1, 2006 and December 31, 2006.) One would assume the Lumagen site is more accurate than the Silicon Optix site.

This is not true. One Realta can run the CNR algorithm as well as an "Edge Adaptive/Diagonal Edge detection" algorithm.

Mark, that list is pretty accurate it seems to me (although the Cinetron projector is not on there I notice - I'll get that updated). Is there something you notice is incorrect or missing there?

Thanks,

Andy K.
ASIC Design Engineer
Silicon Optix Inc.

From algolith :
"Whenever you turn on CNR on the Dragonfly, you loose some of the great Teranex software algorithms for deinterlacing, hence this causes jaggies to become more apparent on the image"

From my DPX-1300:
After reading this, I turned off DVDR(== CNR == Algolith MPEG Noise reduction).

Wow!
There is great improvement in jaggies.
Now "Jaggies Pattern 2" test score becomes 4.5 from 3.
And "Falg" test score becomes 4.5 from 3.

From algolith :
"Whenever you turn on CNR on the Dragonfly, you loose some of the great Teranex software algorithms for deinterlacing, hence this causes jaggies to become more apparent on the image"

From my DPX-1300:
After reading this, I turned off DVDR(== CNR == Algolith MPEG Noise reduction).

Wow!
There is great improvement in jaggies.
Now "Jaggies Pattern 2" test score becomes 4.5 from 3.
And "Falg" test score becomes 4.5 from 3.


When do you get it?

Get your facts straight.

You said the "Realta" cannot do it.

Kromkamp replied that it in fact CAN do it, and there is no reason not to believe that knowing who he is.

The device that might or might not work for this is the "Dragonfly" which is still paper-only. Thus it might be the implementation of the chip by Algolith that does not reflect its capabilities. And tbh I doubt that they will release the Dragonfly that way.

When do you get it?
The device that might or might not work for this is the "Dragonfly" which is still paper-only. Thus it might be the implementation of the chip by Algolith that does not reflect its capabilities. And tbh I doubt that they will release the Dragonfly that way.

Dragonfly is saying that they implemented both, but can not run both at the same time.

How could you be sure about HQV?
Do you have HQV, or are you from Siliconoptix.
If you are one of the above case, your words can be more respectable.

This sounds like yet another username for mbrian.

that would be 3 or 4 usernames for one user. Isn't that a vioaltion of AVS forum's rules?

ads1238 would be another username to look into

kromkamp stated that the Realta chip has no problems running both algorithms simultaneously.

So, if the Dragonfly really cannot do it, then it is Algolith's implementation that is not optimized (yet?).

kromkamp stated that the Realta chip has no problems running both algorithms simultaneously.

So, if the Dragonfly really cannot do it, then it is Algolith's implementation that is not optimized (yet?).
Or that Algolith are adding in code that SO isn't.

So, if the Dragonfly really cannot do it, then it is Algolith's implementation that is not optimized (yet?).

Oops!
My VantageHD screwed up Jaggies.

kschmit2:
What the company out there well implemented HQV?

yet another mbrian account?

Good thing is that Bob Sorel is already looking into the multiple-account issue, but I doubt that he can follow all these threads and thus has to rely on users reporting them. I am not going to report any of these threads that mbrian participates in, as I want to leave that up to others (hint :) )

mbrian,

:(

you are wearing us out...

Ofer:

I can second that

thebland,

I don't think we'll get a realistic answer at this point. There are simply too many variables on this unit - including some of the parts, the HQV software, etc. I know that Lumagen was justifyably quite worried about missing deadlines (HDP Pro, et al) and so I don't think we'll get a firm release date until the beta program is well under way.

Let me be a little more clear so we're all on the same page.

Realta naturally has a fixed amount of processing available inside of it. (Blame Physics :) ) We use that processing power to the best advantage no matter what mode we are in.

So, if we are running deinterlacing-only, we use the full processing power for deinterlacing. Naturally this will give the highest amount of deinterlacing performance.

If we are running both CNR and deinterlacing, we split the processing power between CNR and deinterlacing. Naturally this will mean that less processing power is allocated to the deinterlacing task than in the 'deinterlacing-only' example, and so deinterlacing quality will be slightly reduced.

However, it is emphatically not true that we are removing any features from deinterlacing when the CNR is turned on. We are still very much running a deinterlacing algo that is per-pixel film/video, with all the same cadence detection, and with "edge/diagonal detection" enabled. The quality of these features is still operating at a very high rate. I would not categorize any of these deinterlacing features as 'disabled' in this mode.

Deinterlacing quality on a dual (or triple, or n-tuple) Realta system would, in theory, be even better than a single Realta system. I'm sure you would agree that does not mean that deinterlacing is 'disabled' on a single Realta design :)

Cheers,

Andy K.
ASIC Design Engineer
Silicon Optix, Inc.

So, if we are running deinterlacing-only, we use the full processing power for deinterlacing. Naturally this will give the highest amount of deinterlacing performance.

If we are running both CNR and deinterlacing, we split the processing power between CNR and deinterlacing. Naturally this will mean that less processing power is allocated to the deinterlacing task than in the 'deinterlacing-only' example, and so deinterlacing quality will be slightly reduced.

However, it is emphatically not true that we are removing any features from deinterlacing when the CNR is turned on. We are still very much running a deinterlacing algo that is per-pixel film/video, with all the same cadence detection, and with "edge/diagonal detection" enabled. The quality of these features is still operating at a very high rate. I would not categorize any of these deinterlacing features as 'disabled' in this mode.Andy,
Then what is being sacrificed when sharing the processing? If features are not disabled, is it a shift of algorithms within the deinterlacing process, or a reduction of math accuracy within the algorithms?

Wouldn't both the CNR and deinterlacing routings also vary in processor demand independently based on the contents of a frame? Are they each dynamically adjusted in overall performance accuracy to stay below 100% utilization in real time, or what?

Could you elaborate a little?

--Bill

Hi Bill,

Unfortunately I'm not sure how much I can really dig into details. Some of the hoops we jump through are pretty nifty, and naturally highly proprietary :)

In general, you're on the right track. Also, sometimes its a case of getting 95% of the performance for 50% of the algorithm cost. That last 5% is always the most expensive, computationally.

We do have a whole lot of flexibility without having to completely add or drop features.


Mark, I did mention to our guy at work about updating the HQV products list, just FYI.

Thanks,

Andy K.
ASIC Design Engineer

Deinterlacing quality on a dual (or triple, or n-tuple) Realta system would, in theory, be even better than a single Realta system.Sounds like those who want the highest quality should daisy chain scalers. :)

I'm only half kidding as it does sound like a digital Mosquito separate from a scaler would allow the HQV in the scaler to dedicate more cycles to deinterlacing, for instance.

--Darin

Sounds like those who want the highest quality should daisy chain scalers. :)
SIMD processing really comes into its own with multiple processors. It's only a matter if logistics and cost.

I'm only half kidding as it does sound like a digital Mosquito separate from a scaler would allow the HQV in the scaler to dedicate more cycles to deinterlacing, for instance.

--Darin

Well, not so much as kidding.
Cuz, Crystallio II even has no CNR. :p

But, I think you touched down right conclusion like me.
I already bought MosquitoHDMI. :)

Next thing is about Jaggies performance.
Crystallio II has additional Faroudja for user to play with.
Hmm...

Well, not so much as kidding.
Cuz, Crystallio II even has no CNR. :p
PixelMagic have stated quite explicitly that they have no desire to compete with the Mosquito.

On the other hand, the CII has two video pipelines, so you can in theory take the video from one input, output it to a Mosquito, loop it back through the CII, then scale and process it, before outputting it to your display.
They did talk about the possibility of allowing deinterlacing with the FLI2300 on the first pipeline and scaling with the VXP on the second pipeline (thus allowing you to feed the Mosquito a progressive signal), but I'm not sure if that became a reality or not.

On the other hand, the CII has two video pipelines, so you can in theory take the video from one input, output it to a Mosquito, loop it back through the CII, then scale and process it, before outputting it to your display.


This old for me.


They did talk about the possibility of allowing deinterlacing with the FLI2300 on the first pipeline and scaling with the VXP on the second pipeline (thus allowing you to feed the Mosquito a progressive signal), but I'm not sure if that became a reality or not.

But this is new to me.
Thank you.

EDIT:
Well, Is it theory or rumour that Mosquito will do better process progressive than interlaced - Is it only for film authoring source?!
Anyway, very interesting feature to anticapate.
It will be an another fun to see and test the above story.

But this is new to me.
Thank you.
I should make clear that I'm not sure if that made it into the final design or not.

EDIT:
Well, Is it theory or rumour that Mosquito will do better process progressive than interlaced - Is it only for film authoring source?!
It's easier to detect compression noise when you can see it all. At least in theory.

Some comments from Lumagen:

We decided to put the VisionHDQ as a higher priority to get it out fast, and out of the way of the Radiance design. Unfortunately, one of our chip vendors spec was horrible, and they even left out necessary external components, without which the part does not work correctly. Needless to say, this caused a board spin. So the VisionHDQ took much longer than it was supposed to. Okay a common theme, but blame this one on the chip vendor. The good news is we are now shipping the VisionHDQ production and we have been back on the Radiance for a while now.

We did take a schedule hit by putting the Radiance to the side to complete the VisionHDQ. So, I am now looking at September for Beta. This is, of course, only an estimate.

Features remain as discussed previously. Six HDMI in, four analog in. two HDMI out.

I don't want to get into too much detail about the Radiance design, but I will say we now have four FPGA's in the design, with over twice as many FPGA gates as the VisionPro HDP has. We will be able to preprocess the video before sending it to the Realta chip, and post process after. This allows us to add our stuff on top of the already great deinterlacing and noise reduction processing of the Realta chip. Preprocessing is mostly for calibration, and the biggest part of post processing is for using Lumagen's "non-ringing" scaling algorithm and more calibration work.

Thanks Jim.

Questioned fully answered!

...
Well, Is it theory or rumour that Mosquito will do better process progressive than interlaced - Is it only for film authoring source?!
...


Doing any kind of filtering on interlaced material is very difficult as vertically you have gaps in your data, if you ignore those gaps you introduce artifacts (not unlike what you get with QUE). So i think its true and not just a rumor.

John.

Doing any kind of filtering on interlaced material is very difficult as vertically you have gaps in your data, if you ignore those gaps you introduce artifacts (not unlike what you get with QUE). So i think its true and not just a rumor.

John.

Yes.

But Mosquito will evetually receive two consecutive fields.
Then, if they are smart enough, they can temporarilly construct frame for MNR.
May be it is better way if the external VP is not strong.

From the Mosquito Manual, they say "Audio Delay is negligible".
Hmm, it looks they like they just process interlaced fields directly.

Then about HQV,
HQV has deinterlacing and CNR both in one platform.
It can do 480i->480p and CNR and then upscaling.
Theoretically, HQV has the best environment to remove Mosquito Noise.
But not sure how its real flow is.

Some comments from Lumagen:
I don't want to get into too much detail about the Radiance design, but I will say we now have four FPGA's in the design, with over twice as many FPGA gates as the VisionPro HDP has. We will be able to preprocess the video before sending it to the Realta chip, and post process after. This allows us to add our stuff on top of the already great deinterlacing and noise reduction processing of the Realta chip. Preprocessing is mostly for calibration, and the biggest part of post processing is for using Lumagen's "non-ringing" scaling algorithm and more calibration work.

To me, four FPGA's sounds like more powerful than 2 Realta chips.
I thought there must be something to justify MSRP of $6000.

Very interesting!!

Yes.

But Mosquito will evetually receive two consecutive fields.
Then, if they are smart enough, they can temporarilly construct frame for MNR.
May be it is better way if the external VP is not strong.



I'm not sure but "smart enough" may = deinterlace. Although thinking about it the main thing you need to spot is film vs video mode, that way it may be possible to process video mode fields independently (due to how they're compressed) and film mode fields together.

The other problem is that you want to apply MNR _before_ any scaling as this tends to merge the MN with the rest of the image making it much harder to remove.

Feels like the best solution is going to all be in one box...

John.

Although thinking about it the main thing you need to spot is film vs video mode, that way it may be possible to process video mode fields independently (due to how they're compressed) and film mode fields together.
Many (most?) popular compression schemes compress field pairs together even if the source is video rather than film.

- Dale Adams

Many (most?) popular compression schemes compress field pairs together even if the source is video rather than film.

- Dale Adams

I thought the feilds where generated/compressed independently, but the macro blocks in the "current" field can come from any other field be it odd or even? Otherwise it sounds like you'd always have to fully deinterlace before apply MNR.

Cheers,
John.

I thought the feilds where generated/compressed independently That's not what I've been told by someone much more knowledgeable in this area than I am. Apparently even when the source is video instead of film, compression is applied to a pair of fields weaved together. I've also seen empirical evidence that this is the case.

- Dale Adams

I almost had the opportunity to get a Teranex and a Lumagen working together!
The system we are working on incorporates both a Denon 5910 and a Vision pro HDP.The Lumagen works great with the native resolution H 20 Directv receiver!
I felt the 1080p DVD player could feed the HDMI input while the Lumagen at 1080p would feed the DVI input of the upgraded Qualia 004.Unfortunately the 004 only accepts 1080p on the DVI input. After discussing things with Jim at Lumagen I fed the DVI 480p signal to the Lumagen hoping to use the deinterlacer in the Denon and then the scaler from the Lumagen for a kind of ulimate melding of products.
As has been the case quite a few times I was defeated by HDCP. The Lumagen would not lock on to the output of the HDCP from the Denon. Jim graciously offered to fix the problem if I shipped the Denon to Oregon. Considering the weight of this brute I decided to use a DVI switcher from Gefen and feed both DVD and Lumagen to the DVI input. Have not completed that yet. Next week sometime.

That's not what I've been told by someone much more knowledgeable in this area than I am. Apparently even when the source is video instead of film, compression is applied to a pair of fields weaved together. I've also seen empirical evidence that this is the case.

- Dale Adams
Oh Ok, just sounds kind of counter intuitive as you'd think motion would then introduce higher frequencies into the macro block making it harder to compress.

Later,
John.

Oh Ok, just sounds kind of counter intuitive as you'd think motion would then introduce higher frequencies into the macro block making it harder to compress.That was exactly my reaction as well. :confused:

- Dale Adams

We are actually seeing this when you have a video source with some low frequency data and high frequency data combined:

e.g., a soccer match on green grass where the grass is relatively uniform and the players are running on the field. Any cadence you apply to it will comb, but you can definitely see different cadences working on this source.

The reason is that the MPEG encoder is actually assuming there is film mode present and creates false cadence locks that cause this problem later on during decoding.

So, what Dale is saying is exactly right, there are encoders that are making our life harder by applying this type of nonsense.

jrp,

It would be very interesting to see the combination of the HQV with your scaling technology. I personally like the Lumagen scaling better than HQV scaling, so the combination should be lethal.

ddingle,

my experience leads me to believe that the 5910 is not as robust an implementation of HQV as later designs. I have seen other HQV stuff that outperforms 5910, so keep that in mind.

That's not what I've been told by someone much more knowledgeable in this area than I am. Apparently even when the source is video instead of film, compression is applied to a pair of fields weaved together. I've also seen empirical evidence that this is the case.

- Dale Adams

Well,
then the first conjecture - Mosquito process better progressive than interlaced - is just a rumor rather than a theory.

Becuae by simple weaving(just combining) two fields at the Mosquito side, it will get all the information for macro block.

EDIT:

Compared to my empirical experience to encoding, if the source Macro Block to be encoded contains comb(saw teeth) - much high frequency, then bandwidth to encode it correctly need to be much wide. Can not see what benifit is there compared to encoding just field by field - no high frequency - exact image encoding.

Anyway, two theory
- compression is applied to a pair of fields weaved together
- Mosquito process better progressive than interlaced
are contradictory, they can not stand up at the same time.

The issue is that there's no gaurantee that that's what the encoder has done though, so in theory this makes it even more important to deinterlace before you apply MNR.

John.

To me, four FPGA's sounds like more powerful than 2 Realta chips.


I think it's premature to make any kind of judgment like that: we don't know what kind of FPGAs are being used, where they're being used, and how they're connected to the rest of the system and to each other.

--Andre

jrp,

It would be very interesting to see the combination of the HQV with your scaling technology. I personally like the Lumagen scaling better than HQV scaling, so the combination should be lethal.

ddingle,

my experience leads me to believe that the 5910 is not as robust an implementation of HQV as later designs. I have seen other HQV stuff that outperforms 5910, so keep that in mind.

Thanks! Jim indicated that deinterlacing was the HQV strong point. I must say the old Video Essentials disc I still use, looked better than with any other processor in memory. The leaves and the stadium seats looked close to perfect.
Jim as you mention felt the Lumagen would be a better scaler and it would have been nice to get the combination going,but as mentioned HDCP problems kept that from happening.
Overall sound and picture quality of the 5910 is not to be complained about too much anyway. $3500 should buy a good DVD player :)

That's not what I've been told by someone much more knowledgeable in this area than I am. Apparently even when the source is video instead of film, compression is applied to a pair of fields weaved together. I've also seen empirical evidence that this is the case.

- Dale Adams


So, what Dale is saying is exactly right, there are encoders that are making our life harder by applying this type of nonsense.

From here,

http://www.fh-friedberg.de/fachbereiche/e2/telekom-labor/zinke/mk/mpeg2beg/beginnzi.htm

I found this:
-----
In the field structure, the two fields of a frame may be coded independently of each other, and the odd field is followed by the even field. Each of the two fields has its picture header.
-----

We need more checking.

In the field structure, the two fields of a frame may be coded independently of each other, and the odd field is followed by the even field. Each of the two fields has its picture header.Just because they 'may' be, doesn't mean they are. The MPEG spec allows for a number of variations. Common practice, however, apparently is to code field pairs together.

- Dale Adams

mbrian,

you "may" be wrong.

How could mbrian be wrong when he is so sure he is right? Maybe tomorrow he will post his impressions beta testing DVDO's "ABT103" 1080i ultimate precision deinterlacing.

We're a hard crowd here...

It is not the standard to chide someone, but I could not resist with Ofer acting as the Master of the Ceremony.

Every answer to a question can either be correct or incorrect. That's it. Even a simple I do not know. That would be correct. The problem here is that some people who don't know, don't know that they don't know. Personally, I'm clueless.

some people who don't know, don't know that they don't know.

That reminds me of a verse from Monty Python:
I know what I know and thats all I have to say about it :)

It is just information:

From here:
http://www.faqs.org/faqs/mpeg-faq/part3/

I found this:

--------
Is the encoder standardized ?

A. The encoder rests just outside the normative scope of the standard,
as long as the bitstreams it produces are compliant.
--------

And this:

--------
Two methods can be applied to interlaced video that maintain
syntactic compatibility with MPEG-1 (which was originally designed for
progressive frames only). In the field concatenation method, the
encoder model can carefully construct predictions and prediction errors
that realize good compression but maintain field integrity (distinction
between adjacent fields of opposite parity). Some pre-processing
techniques can also be applied to the interlaced source video that
would, e.g., lessen sharp vertical frequencies.

This technique is not terribly efficient of course. On the other hand,
if the original source was progressive (e.g. film), then it is more
trivial to convert the interlaced source to a progressive format before
encoding. (MPEG-2 would then only offer slightly superior performance
through such MPEG-2 enhancements as greater DC coefficient precision,
non-linear mquant, intra VLC, etc.) Reconstructed frames are usually
re- interlaced in the Display process following the decoding stages.

The second syntactically compatible method codes fields as separate
pictures. Rumors have spread that this approach does not quiet work
nearly as well as the pretend its really a frame method.
----------

1. field concatenation method : the above weave method
- not terribly efficient of course, if not lessen sharp vertical frequencies
- will do if the original source was progressive (e.g. film)

2. codes fields as separate pictures.
- will do both video and films.

If someone else have another good infomation, make the link please
so that I can read and learn.

Cheers,

The filtering in the Mosquito is content adaptive therefore, if the unit is getting fields or frames, it will adjust its filter size accordingly. There shouldn’t be any differences between the two in term of filtering performances.

We never combine the two fields to figure out the block structure.

From what I have seen, most encoders will interlace the two fields together before compressing. In this case, when you playback the content (in interlaced mode), you will get 8x4 block size (instead of 8x8). Because of this situation, interlaced and non interlaced compressed images are addressed differently by the mosquito to account for the image differences.

The Mosquito audio delay is 20 video lines. So it is easy to calculate, it depends on the video format…

Thank you Jacques!

I am MosquitoHDMI user.

Would you care for the my findings in:
http://www.avsforum.com/avs-vb/showthread.php?t=662325

I am waiting for new firmware release and the new version come up with some fix.


There shouldn’t be any differences between the two in term of filtering performances

So, we do not need to feed 480p insted of 480i. Is it conclusion?!


The Mosquito audio delay is 20 video lines. So it is easy to calculate, it depends on the video format…

20 video lines?!
After I getting Crystallio II(end of April!), I want to compensate the delay caused by Mosquito, if possible.
Could you be more specific.
Do you mean 20 video scan lines in 480 lines?
Then, it is really negligible.

If we are running both CNR and deinterlacing, we split the processing power between CNR and deinterlacing. Naturally this will mean that less processing power is allocated to the deinterlacing task than in the 'deinterlacing-only' example, and so deinterlacing quality will be slightly reduced.



Cheers,

Andy K.
ASIC Design Engineer
Silicon Optix, Inc.

Does this mean feeding a deinterlaced(progressive) signal to the RADIANCE(realta chip) will give you a better CNR resault ?

The filtering in the Mosquito is content adaptive therefore, if the unit is getting fields or frames, it will adjust its filter size accordingly. There shouldn’t be any differences between the two in term of filtering performances.

We never combine the two fields to figure out the block structure.

From what I have seen, most encoders will interlace the two fields together before compressing. In this case, when you playback the content (in interlaced mode), you will get 8x4 block size (instead of 8x8). Because of this situation, interlaced and non interlaced compressed images are addressed differently by the mosquito to account for the image differences.

The Mosquito audio delay is 20 video lines. So it is easy to calculate, it depends on the video format…

Hi Jacques,

interresting information, but I have to say that its left me more confused than I was previously.

Basically you seem to be suggesting that you treat interlaced material as having a block size of 8x4. To me this implies that you can't get as good a result as with non interlaced material due to fact that, irrespective of the source material being progresive, video, weaved video etc, the dct/quantised block size within the encoder is always 8x8 (for MPEG2).

Regards,
John.

guys, we're hijacking this thread.

Keep in mind that this thread is about the Lumagen Radiance, so lets keep on topic.

If someone wants to discuss field combining, just open a dedicated thread.

Back on track...I posted a response in another thread regarding a comparison of moving from a Lumagen to an Anthem D2 (http://www.avsforum.com/avs-vb/showthread.php?p=7515518&&#post7515518) and it really has me thinking since I am considering an HD DVD Player purchase. I am a happy owner of a VisionPro HDP and assumed the Radiance was in my future. I am hoping Jim Peterson may pop back in here and share his thoughts on how he thinks Audio in the Radiance is going to be implemented.

From everthing I am reading regarding the release of HD DVD and assuming that Blu Ray is following along the same path, Optical and Digital Coax audio is dead. It is all about HDMI starting with v1.1 being the minimum requirement. In order to successfully use one of the new HD formats and take advantage of the audio capabilities it is not optional, but necessary unless I am misunderstanding something. Jeff, thebland, who started this thread hopefully will jump in as he has been very vocal in the problems created for audio with his new Toshiba HD A1.

------------------------------------------------------------
Taken from the thread linked above and re-phrased a bit:

Traditionally in the past we thought about Video Processors for Video Only. With the advent of HDMI, we must also think how audio will be handled and the interaction of not only the VP and the display, but also the Audio Receiver or Pre/Pro.

Based upon what has been reported so far with regard to how audio is handled in HD DVD and it looks to be similar for Blu Ray, I am concerned how a future stand alone video processor is going to function mainly due to the emergence of HDMI Audio. Since Audio and Video are carried on a single HDMI cable the Video Processor must be connected to an HDMI capable Pre/Pro or Receiver.

Take this scenario (All sources are assumed to be connected via HDMI for Video and Audio):

VP HDMI Input #1 - HD Cable or Sat STB
VP HDMI Input #2 - HD DVD (because you have to have it)
VP HDMI Input #3 - Blu Ray (because you have to have it also even though your wife is yelling at you...)
VP HDMI Input #4 - SD DVD Player w/480i HDMI output (still have one assuming neither of the above output 480i via over HDMI ala the just released Toshiba HD DVD Players)

VP Output via HDMI must be plugged into an HDMI Pre/Pro or Receiver and not directly to a display because you need to get audio to the Pre/Pro or Receiver, then you must output HDMI from your Pre/Pro or Reciever to your display.

This sounds like a nightmare waiting to happen to me. You think there are HDCP handshaking problems now, just wait until you start daisy chaning more items together. What if the HDMI implementation in the Pre/Pro or Receiver doesn't play well with non standard video resolutions and its HDMI inputs only want to see 480, 720 or 1080. Sounds like a nightmare for a stand alone video processor unless they can somehow separate the audio and video and have an HDMI Video Output and HDMI Audio Output.
------------------------------------------------------------

I would love to hear some other thoughts on this.

Regarding further thoughts on the Radiance, Jim already mentioned besides the Radiance XD that more than likely there will be a Radiance XS (single output?) with a lower MSRP. Personally I would like to see another member of the Radiance family...An All Digital Radiance, Digital In and Digital Out, no analog inputs or output, it is time to let the legacy stuff go... If HDMI is it and it is here to stay, 6-8 HDMI inputs with independent outputs for HDMI Video and HDMI Audio if this is even possible.

I've never seen mention of any other planned model except the Radiance in the Lumagen roadmap.

Ofer, here is a quote from Jim Peterson from this Thread (http://www.avsforum.com/avs-vb/showthread.php?p=7167518&&#post7167518)

Nothing official, but expect the less expensive Radiance product to have a single HDMI output and probably four HDMI inputs (verses six on RadianceXD), plus four analog in (same as RadianceXD). The name for this product may be the RadianceXS (since is it's a single output), but we are still considering what to call it.

Processing and performance will be identical to the RadianceXD, just fewer HDMI in and only one HDMI out. For example both will use Lumagen scaling and have the Lumagen calibration features. We prefer our scaling (which is designed to not ring) to the scaling done by the Realta chip, and the Realta chip does not have the calibration features we want. So, we use the Realta for deinterlacing and noise reduction, but Lumagen technology for everything else.

Price is not firm yet, but it should be in the mid-4K range in the U.S. with a trade-in credit of 33% for your current Lumagen processor. Trade-in applies to U.S. only. Distributors in other countries set their own trade in Policy.

The RadianceXS may even precede the RadianceXD, since we are getting a lot of feedback to come out with the lower priced Radiance product first.

Would it be possible to get an update from Jim Peterson on the Radiance features and availability?

I think there will be news at CEDIA or slightly prior...so that's 7-14days....

Gordon

Great! The Radience is the scaler I plan to use for a long time. I am very excited about having 2 HDMI outs. Oh and I almost forgot, the HQV chip as well... :) Hopefully by Thanksgiving or atleast Christmas time! Maybe Santa can come thru this year... :D

Bump...any news?

No Radiance of junior Radiance will be at Cedia. There will be some announcements regarding features etc because the design is further along. Can't say more. :)

I think we will see it demoed at CES but I do not expect product until sometime Q1 2007. Good things often take buyers' patience.

Bump...any news?

http://www.lumagen.com/testindex.php?module=news

Marcel J. Dumeny

The best part:

The RadianceXD supports two HDMI outputs at resolutions up to 1920 by 1080, at 60-Hertz progressive. The second HDMI output can be a copy of the first output, or it can be used as an audio only output to send audio to receivers that do not support full 1080p60 for their HDMI inputs. Audio output is supported on the HDMI connections plus two COAX audio outputs.

nice idea!

I hope their engine can support two parallel scaling engines (i.e., set output 1 at one resolution and rate and the other one at another resolution). This can be a great solution for projector + plasma owners.