PDA

View Full Version : Really really bad quality tga importer



Red_Oddity
08-24-2007, 02:56 AM
Okay, it probably is me, but i for the love of god can't get SpeedEdit to import and export tga files in decent quality.
When i import tga files it almost looks as if it creates an ultra low quality proxy movie and displays and uses that for editting purposes.

I have searched high and low, but sure as heck can't find ANY options that could explain this incredibly sh!tty quality.

example :

Fusion render:
http://www.houseofsecrets.nl/downloads/examples/fusion.png

Aftereffects render :
http://www.houseofsecrets.nl/downloads/examples/afterfx.png

Speededit render:
http://www.houseofsecrets.nl/downloads/examples/speededit.png

Just look at that garbage around highlights and text, and the insane banding.

(ps. you have no idea how tempting it was this time to say 'i finally have had it with this piece of poo software, here have your DVDs back and put it in a grinder or something', but i'll refrain from unconstructive comments...for now.)

Lightwolf
08-24-2007, 03:49 AM
I suppose this is because SE only composites/renders in YUV - likely 4:2:2 YUV as well.
You'll never get the same results you can expect from an full sampling RGB render - then again those are the limits of video, which is what SE was designed for.
It does look like it has a bit of a scaling problem though, looking at the width of the type... (why a 768x576 image though?)

Cheers,
Mike

Bobt
08-24-2007, 05:15 AM
I am pretty sure that is artifacting caused by the 2u and 2v that has been
discussed many times in the distant past. Smooth gradients
cause a stair step effect. What you need is 4:4:4 then this would
not occur.
Send it out in AE as YUV 4:2:2 see what you get.

Red_Oddity
08-24-2007, 08:34 AM
okay, then why in Zeus's bollocks give us a deal to have LW 9 in combination with SpeedEdit...Why include a 444 codec while we're at it?
Not everyone thinks 422 or DV is fine for final output, let alone for an online edit.

Still, that does not explain what happens to my text, just look at the 'e' and 'n' of 'Geniet...'

Or why all my colors and luminance values are 'off' when compared to viewing the image in any image viewer.

Really, when you degrade the quality of your material to such a low standard that even a pentium 2 can run it, basically every editor becomes 'the faster editor in the world'.

I think i've somewhat had it with SpeedEdit, seriously, i can not sell these movies to my clients, i really can not.

I think my next investment will be either a new update for that horrible Premiere or a try out for Edius, but i seriously doubt i'll upgrade SpeedEdit when the time comes.

Red_Oddity
08-24-2007, 08:37 AM
Oh and the scaling has to do with a switch to 16:9 mid project, has to do with my 3d comp in Fusion.
For some stupid reason i set the aspect ratio to 1.33 and the width to 768...i must have made that booboo when i was pissed at the client for telling me to change aspect ratios 2 days before the daedline.

Anyway, when scaled to 720 it still is what it should be, 1.42 aspect.

Lightwolf
08-24-2007, 08:40 AM
okay, then why in Zeus's bollocks give us a deal to have LW 9 in combination with SpeedEdit...Why include a 444 codec while we're at it?
Because you'd use that as an intermediate format?


Not everyone thinks 422 or DV is fine for final output, let alone for an online edit.
Erm... which end user video medium is 4:4:4 then? It is prefectly fine for anything video related... just don't use it to generate intermediates. then again, you wouldn't use an editing package for that anyhow.


Still, that does not explain what happens to my text, just look at the 'e' and 'n' of 'Geniet...'

No, it doesn't... and there is something seriously wrong there.
Are you scaling the images on import, or are they 1:1?


Or why all my colors and luminance values are 'off' when compared to viewing the image in any image viewer.

Because SE tries to give you an idea of the video gammut... which is something no other app has seriously attempted to do before. It takes some getting used to, but if you compare the viewer to a real broadcast monitor it is actually quite close.

Cheers,
Mike

Lightwolf
08-24-2007, 08:48 AM
Oh and the scaling has to do with a switch to 16:9 mid project, has to do with my 3d comp in Fusion.
For some stupid reason i set the aspect ratio to 1.33 and the width to 768...i must have made that booboo when i was pissed at the client for telling me to change aspect ratios 2 days before the daedline.

Anyway, when scaled to 720 it still is what it should be, 1.42 aspect.
What does it look like if you scale to 720 in Fusion and then import into SE?

Cheers,
Mike

SBowie
08-24-2007, 09:33 AM
This is a single image, right - not a fg and bg layer comp in SE? (Because it it was the latter I'd be wondering about your alpha pre-mult selection.) Even so, that banding is nasty.

Bobt
08-24-2007, 11:59 AM
The text looks like an overlay issue where the text was shrunk to fit.
Did you try outputing that as a 4:2:2 image from AE or Fusion?
Give it a go.

Rich Deustachio
08-24-2007, 01:30 PM
When you open up the properties of the still in SE is it set for med quality or high quality?

Red_Oddity
08-27-2007, 11:28 AM
Import is 1:1, quality is set to high, progressive, etc etc.

It's a raw 8bit tga, and the videolevels ITU-R BT .601 are done elsewhere (the folks that dump it on tape), it is important for us that our editting software doesn't touch the image whatsoever.

Whatever it is, SpeedEdit does some really weird stuff with my files.

Below are 2 images, grabbed from 2 renders, both using uncompressed AVI as output, using the OneRiverMedia source-pal 16bit png as source.

http://www.houseofsecrets.nl/downloads/examples/uncompressed_afx.png

http://www.houseofsecrets.nl/downloads/examples/uncompressed_se.png

http://www.houseofsecrets.nl/downloads/examples/blowup.png

http://www.onerivermedia.com
or
http://www.houseofsecrets.nl/downloads/examples/source-pal.png

As you can see, SpeedEdit totally screws up colors and details, i have absolutely no idea what the heck is going on.

Red_Oddity
08-27-2007, 11:29 AM
Check the color noise on the blowup.png, Speededit completely scrambles colors, orange and reds all of a sudden become greens, levels are strange, etc.

cholo
08-27-2007, 03:56 PM
In blownup.png, the problem you're seeing is chroma subsampling. You're converting single pixel colored lines into a chroma subsampled format.

Red_Oddity
08-28-2007, 04:21 AM
I think i've figured out what happens by trying to get the same results in Fusion.

SpeedEdit imports footage, then under the hood converts the footage to YUV, when it needs to render or display something it converts it back to RGB, and this is where a lot of the original image is lost (it just happens with YUV).

I'm guessing this is just the way SpeedEdit is supposed to work.

It would be nice to be able to circumvent the RGB -> YUV -> RGB conversion, i'll post this as a feature request, because the way SpeedEdit currently works, while not completely useless is not good enough for intermediates for us.

Lightwolf
08-28-2007, 04:27 AM
It would be nice to be able to circumvent the RGB -> YUV -> RGB conversion, i'll post this as a feature request, because the way SpeedEdit currently works, while not completely useless is not good enough for intermediates for us.
Hm, that would basically mean rewriting the complete render engine to work with RGB data. Mind you... it would be nice, especially as a mode to use when rendering final output (but then I would mind a higher bit depth either ;) )
It has the disadvantage of SE needing to shuffle roughly 25% more data around (24 vs. 32 bits per pixel, including alpha).

Heck, I remember a time when it was a big huge f**ing feature to have a video editor that did not work in RGB but in YUV to stay true in video colour space.

Cheers,
Mike

Bobt
08-28-2007, 04:46 AM
I think it can be addressed if you worked in 4:4:4 YUV internal pipeline.
Its not the bit depth or the conversion. Its the 2:2 part that is making this bad.
Least thats what I have found in experiments with small patches of gradient
material and conversion into 4:2:2 space. The addition of these extra bytes would add a 33% more data per frame. (OUCH) not considering alpha.
I think with multiple CPU's coming of age and DDR3 getting better soon this
can be done. Guess its up to Newtek to see if they want to rewrite an
entire render engine to do it.

Bob

Lightwolf
08-28-2007, 04:49 AM
Guess its up to Newtek to see if they want to rewrite an
entire render engine to do it.

If they do I hope they'll consider 10 bit per pixel as well - or whatever performs well.

Cheers,
Mike

billmi
08-28-2007, 08:24 AM
Heck, I remember a time when it was a big huge f**ing feature to have a video editor that did not work in RGB but in YUV to stay true in video colour space.


Yep, trying to re-build a video editor to make it less good at being true to video colors doesn't sound good to me. IMHO, the route to go would be YUV rendering, instead of RGB, to get in the video pipeline.

Red_Oddity
08-28-2007, 11:04 AM
I think it can be addressed if you worked in 4:4:4 YUV internal pipeline.
Its not the bit depth or the conversion. Its the 2:2 part that is making this bad.
Least thats what I have found in experiments with small patches of gradient
material and conversion into 4:2:2 space. The addition of these extra bytes would add a 33% more data per frame. (OUCH) not considering alpha.
I think with multiple CPU's coming of age and DDR3 getting better soon this
can be done. Guess its up to Newtek to see if they want to rewrite an
entire render engine to do it.

Bob

I sure as heck can't find an option to turn on 4:4:4 color space anywhere...could you explain how this goes? (mind you, i'm using tga files, not encoded SpeedHQ avi files)

anyhoo, i now understand why it's called a video editor.

ScorpioProd
08-28-2007, 11:11 AM
Yep, trying to re-build a video editor to make it less good at being true to video colors doesn't sound good to me. IMHO, the route to go would be YUV rendering, instead of RGB, to get in the video pipeline.
Exactly, one of the major complaints about Vegas 7 is that it is still RGB based instead of the YUV base that those of us doing video would much prefer. Just about ever other true NLE for video is now YUV based.

I realize that Newtek is pushing SE to go with LW, but I think it's important to remember that regular video is still gonna be YUV in the end. So if that's where your output needs to be seen, you need to work within those limits in the creation stage.

ScorpioProd
08-28-2007, 11:12 AM
I sure as heck can't find an option to turn on 4:4:4 color space anywhere...could you explain how this goes? (mind you, i'm using tga files, not encoded SpeedHQ avi files)

That's not an option.

Lightwolf
08-28-2007, 12:07 PM
I realize that Newtek is pushing SE to go with LW, but I think it's important to remember that regular video is still gonna be YUV in the end. So if that's where your output needs to be seen, you need to work within those limits in the creation stage.
Which is basically why a video editor is no good to create intermediates... unless the following steps don't expect more than YUV anyhow.

Cheers,
Mike

Bobt
08-28-2007, 09:33 PM
But it can have if, NewTek wanted, a 4:4:4 internal pipeline with 10 bit
color as well. Its up to them.. Would make it very blue fish compatible.

Bob

rbartlett
08-29-2007, 12:22 PM
But it can have if, NewTek wanted, a 4:4:4 internal pipeline with 10 bit
color as well. Its up to them.. Would make it very blue fish compatible.

Bob

I've seen it said inside these walls that the VT technology that fed into the ethos that brought us to SpeedEDIT had a common 16bit per channel internal representation and a 4:4:4:4 pipeline. So the issue is the render and preview limitations that have been imposed by NewTek and/or Microsoft to maintain realtime and max resolution at all resolutions.

Sony Vegas is 8bit RGBA with a 16bit per channel internal representation. When importing YUV sources like DV the Sony codec caresses the data to get a good match in RGB space. You basically have to work hard to get contouring. MPEG-2 comes into Vegas7 and versions below that using the MainConcept technology first, so the opportunity to get the best match at the same time as doing the color space swap is lost. So making DV and uncompressed the only passthrough formats in Vegas (if you leave all pixels untouched - which is the traditional cuts-only edit workflow but I know I can't help myself but to leave my color themes until I'm in my edit bay).

It is difficult to know where the restriction is derived from. Yet there clearly is one and it would seem that the only way forward at this moment in time is to massage the RGB figures through a pre-processor before SpeedEDIT gets hold of the pixels to do what it does that looks er' a'hem, processed.

I'm not sure what that technology would be at this time, possibly Mirage can remap RGB in a more fitting fashion.

This is one of those situation where you hope that someone has simply forgotten to read the 'carry flag' (as in "add 3, carry one) from the sums/math being done.

ty2000
08-29-2007, 08:02 PM
Oh Heavens no Please don't make it work in RGB! It is GREAT in YUV. use vegas if you have to.

Red_Oddity
09-01-2007, 06:33 PM
I meant please give the OPTION to work in RGB, i never said to ditch YUV, and i didn't upgrade Vegas to buy SpeedEdit because i found the workflow and way of editting in SpeedEdit just to be more the way i think an editor should work for me (Vegas always felt somewhat clumsy, it always kept feeling like Sonicfoundry Acid with some better video previewing)

Why are extra options always seen as a negative on software forums?

Red_Oddity
09-01-2007, 06:45 PM
Also, as BobT suggested, getting a 10bit internal pipeline (4:4:4) would really help, as a lot of the noise and edges around saturated details in my screenshots clearly come from 4:2:2 chroma subsampling.

rbartlett
09-02-2007, 06:02 PM
Red_Oddity - have you tried rendering out a section as:

'Video for Windows AVI - uncompressed 4:4:4:4 - Project Settings'

or

'Rendering out a frames sequence (jpg, bmp,....) - TARGA 32bit - Project Settings'

?

Same thing happens?

Red_Oddity
09-03-2007, 08:09 AM
yes, yes and yes.
The problem already shows up when viewing the footage in SpeedEdit's timeline, when rendered out as any 4:4:4 RGB or YUV file, the subsampling shows up.

Rich Deustachio
09-03-2007, 08:53 AM
Did you send NewTek a couple of the .tga files so they can see how bad it looks?

rbartlett
09-03-2007, 10:34 AM
VT may have been SD only but it was generally accepted that it was 4:4:4:4 capable. As such many 3D animators used VT instead of reverting back to DPS/Leitch/Harris Velocity workstations. In fact, rendering to BGR32 was and is a regular workflow for AVIs from VT.

So why not SpeedEDIT too. Is the speed required for HD functionality forcing the pipeline into 4:2:2 (and 4:2:0 for many of the renderers default settings).

I don't mind so much if the preview quality is 4:2:2 as this may help lowered spec'd machines - assuming that gfx cards can benefit from being directed to blocks of pixels in this packing format. 99% of monitors on PCs being RGB based ultimately.

One day we'll not need compression codecs and this Y'CbCr subsampling business will be gone. As will interlaced trickery. Not there yet but I'd expect that LightWave remains one of the more significant avenues that NewTek wish to pursuade SE into. As a tool of necessity really, not convenience.

ScorpioProd
09-03-2007, 03:34 PM
VT may have been SD only but it was generally accepted that it was 4:4:4:4 capable.

Are you sure about that, Richard? I thought VT was always 4:2:2, period. I mean, VT handles D1 video, and D1 video is 4:2:2.

rbartlett
09-03-2007, 04:23 PM
In the context of the hardware and the NewTek supplied codecs, yes 4:2:2. However as I remember such commentaries about the 4:2:2, I'm sure I remember there being addendums to a number of threads (including Dr Cross and Mr Tasa - although I may be mistaken) explaining that internally the processing was 4:4:4:4. Processing formats, cached formats and ingestable/renderable formats can all be quite different things. As can internal bits per channel and oversampling for "ISS" modes.

On this occasion I'd not like to be wrong! I'd hope that the VT hardware was the 4:2:2 limiter to allow it to work on the limited bus bandwidth in as wide a volume as the card and the various SX/SD adapters/daughterboards would allow it to achieve on the PCI bus itself. (so there followed that the digitizer would also sub-sample color to half of the XY resolution of the luminance).

Perhaps I am remembering it wrongly or perhaps the description didn't have the right amount of clarification about what was being spoken of. It may have been a quote about Aura or Mirage I suppose.....

rbartlett
09-03-2007, 05:00 PM
Actually, I can see no sign of the internal pipeline for VT or SE ever being claimed as being a 4:4:4:4 pipe. I think I've tried to put the words in their mouths a few times, this post now counts as an extra time. My apologies.

However all is not lost, there are 16bits in the 4:2:2 pipeline and SpeedHQ itself can preserve 11 bits of these 16 pipeline representations. As determined from the below.

Quite where this thread should go now in order to assist Red_Oddity, I'm not sure exactly. I'd personally evaluate whether the final format is going to be 4:4:4, 4:2:2, 4:2:0 for starters. I've always thought of all NewTek products as being BGR32 friendly as opposed to compromised. Not just from a reading compatibility perspective but also from a fully-serving aspect.



Here the result of is my search for 4:4:4 and 4:4:4:4 on YahooGroups (VTNT):



http://tech.groups.yahoo.com/group/VTNT/message/100158

Re: [VTNT] Re: No compromise codec suggestion for HD?

Actually, SpeedHQ is a full "real" 11 bit codec with higher precision
processing (16 bit or better) to ensure that all 11 bits are preserved,
which has twice the dynamic range of what CineForm allows.




http://tech.groups.yahoo.com/group/VTNT/message/99263

Re: [VTNT] Re: SpeedEdit support question

> Is there an opportunity, codec/null-codec permitting to send in 16bit
> data (YUV or RGB) and save SpeedEDIT from having to do this initial
> conversion? In a way that would be passthrough all the way up until
> you rendered, which would then be ideally transformed to 8bit YUV to
> suit the large majority of delivery formats?

I am afraid not. However because we process at higher than 8 bit, as
long as you do everything right (not quite as simple as you think) then
8 bit source footage material will be EXACTLY correct on the other end
of the processing chain (this is something I have verified with a hex
editor.) Unfortunately most sources are now 8 but, 420 and compressed -
although higher resolution.

Alpha is handled in 16 bits as well.

All of the above is somewhat "hand-saving" because the true processing
is very complex and so it is hard to give answers that don't involve
more explanation than anyone would be interested in.

Andrew




http://tech.groups.yahoo.com/group/VTNT/message/99260

Re: [VTNT] Re: SpeedEdit support question

That information is still correct today. SpeedEDIT actually does do
things slightly better than VT-Edit did in a number of ways.

Richard Bartlett wrote:
>
> I did some digging and found these words to support my memory. This
> was a post from Dr Andrew Cross, regarding VT but very likely to still
> be pertinent today with SE:
>
> http://tech.groups.yahoo.com/group/VTNT/message/35033
> <http://tech.groups.yahoo.com/group/VTNT/message/35033>
>
> <Andrew quote from Jan27 2003>
> When the Toaster does RGB to YUV (or vice versa) color conversion,
> internally it does all calculations in 16 bits per pixel. Rather then then
> rouding the the nearest 8 bit destination value it will choose a
> dithered 8
> bit destination, giving it an effective color precision that exceeds 8
> bits,
> and should never give any visible artifacts. There are two additional
> things
> to note here :
>
> 1) The Toaster is uncompressed, which allows us to perform some dithering
> tricks to acheive effective color precisions beyond 8 bits. If we where
> running through a DCT operation, pretty much everything would be truncated
> and result in bandind og a drop in chroma resolution.
>
> 2) We only ever actually convert color space when and if we actually need
> to. Within TEd it is only possible to perform a single RGB -> YUV color
> conversion process, and then it is never needed to convert back (even
> for DV
> file writing.)
> </Andrew quote from Jan27 2003>





http://tech.groups.yahoo.com/group/VTNT/message/61232

Curtis,

Internal processing inside VT is typically done in 16bits, although this
is then truncated to 8bits for output. So, if you take RGB color
conversion for example, all data is converted to 16 bits, the color
transformation done in 16bits (with dithering to avoid banding) and then
truncated to 8bits for output.

The same goes for 3D positioning, blurring, color correction, etc...
One exception is that in the new high quality mode in the scaling, color
is temporarily stored and weighted in floating point.

Andrew

>I didn't notice anywhere on the page. Is this still only 8-bit YUV or have
>we moved up to a higher bit depth for processing things like RGB video?
>Thanks to those who know! :)
>Curtis
>
>GO BRAVES!!!
>