Which color space would be best for lossless compression purposes ?
Skybuck Flying
Which color space would be best for lossless compression purposes ? and why
?
Compression techniques could be:
1. Runtime Length Encoding. (Good when many repeting colors next to each
other)
2. Sliding Window Color Lookup with smaller index. (Good when many repeting
colors near each other)
Color space could be:
1. RGB,
2. R'G'B',
3. XYZ,
4. L*a*b*,
5. L*u*v*,
6. Y'PbPr,
7. Y'CbCr,
8. Y'IQ,
9. Y'UV
Bye,
Skybuck.
Skybuck Flying
space... similiar to maybe y'uv but with different percentages.
I'll have to think about that and figure it out ;)
It should be designed in such a way that no loss of color information will
occur when it's stored in bytes as efficiently as possible.
Bye,
Skybuck.
arahne
> Hello,
>
> Which color space would be best for lossless compression purposes ?
Strictly speaking, in a digital world, the same colorspace
as the original image, as the conversion into a different colorspace
and back will sometimes change some bits ;-)
Or if you want to ensure all bits remain the same after converting
the color space two times, then you will need to use higher
number of bits in the compression space, which works against your
goal of compression.
DuĊĦan Peterc
http://www.arahne.si
Thomas Richter
> Hello,
>
> Which color space would be best for lossless compression purposes ? and why
> ?
None. Compression doesn't care about "color space". Are you potentially
asking about a lossless decorrelation transformation? If so, in which
color space is the original data recorded?
> Compression techniques could be:
>
> 1. Runtime Length Encoding. (Good when many repeting colors next to each
> other)
Why should that do any good? What is your initial data? Photographic
images? If so, RLC does almost nothing.
> 2. Sliding Window Color Lookup with smaller index. (Good when many repeting
> colors near each other)
What is that?
> Color space could be:
Is that the input color space?
Look, it's really unclear what you want to know. In your list, there is
no pair of color spaces that can be transformed into each other without
loss. If you want to run a "color space conversion" to ease compression,
then that's a decorrelation transformation. In JPEG2000, the RCT is
used, basically expecting some "RGB-like" color space as input and
creating some "YCbCr-like" color space as output, but again, this does
*not* define a color space in the strict sense. It is a lossless
transformation that is expected to decorrelate the color planes of the
input image expecting some typical statistics of the input data.
So long,
Thomas
Skybuck Flying
I thought the YUV conversion had something to do with it.
Now I am not so sure anymore.
I guess I will have to understand it the hard way...
By analyzing and reverse enginering the source codes of the codec ;)
By the way JPEG'S RCT requires extra bits as well for lossless conversion...
Thanks anyway.
Bye,
Skybuck.
Skybuck Flying
contains MASM asm crap which the Visual Piss Studio chokes on as usual.
From the looks of it the MASM shit looks tricky/awfull, so porting to Delphi
might be difficult as well.
Maybe I can find some shitty MASM tool somewhere and get it fucking working
in the fucking studio.
:(((((((((((((((
;)
Bye,
Skybuck.
Thomas Richter
> I want to understand why HuffmanYUV codec achieves 50% compression.
>
> I thought the YUV conversion had something to do with it.
No, and it doesn't perform "compression" by representing it differently. (-:
What does happen, pretty often, is that after conversion to YUV the U
and V components are subsampled, i.e. only every fourth (or every n-th)
pixel is transmitted. This doesn't hurt visual quality a lot since the
human eye is less sensitive to color than to luminance, but this
operation is neither lossless (clearly) nor specific to YUV (it would
work with other color spaces that separate color from luminance).
(Traditional) JPEG works this way.
> By the way JPEG'S RCT requires extra bits as well for lossless conversion...
Yes, but it makes the result more compressible, so the bit is well-invested.
So long,
Thomas
LordO...@googlemail.com
> I want to understand why HuffmanYUV codec achieves 50% compression.
>
> I thought the YUV conversion had something to do with it.
>
The commonly used YUV 4:2:0 format gives an immediate 33% reduction in
size by storing chroma samples (CbCr or "UV") at half the horizontal
and vertical resolution of luma samples ("Y"). The organisation of
data is normally planar, for example a 4 by 4 pixel image will often
be stored as:
Y,Y,Y,Y,
Y,Y,Y,Y,
Y,Y,Y,Y,
Y,Y,Y,Y,
U,U,
U,U,
V,V,
V,V.
This is therefore a LOSSY encoding, but one that could reasonably be
described as PERCEPTUALLY LOSSLESS for the typical observer (i.e. it
is hard to see the difference between an original RGB image and one
converted to YUV then back again, PROVIDED all transformations and
intermediate storage are sufficiently precise).
It is feasible that planar YUV could be efficiently compressed using
RLE, VLC (e.g. Huffman, Arithmetic Coding) or some combination of
techniques but this depends a great deal on the properties of the
image...
The Discrete Cosine Transform followed by coefficient reordering as
used in JPEG (NOT JPEG2000) and MPEG1,2,4 operates on blocks of planar
YUV data and effectively "shuffles" the important information into a
small number of bits, with the balance of (mostly) zero bits trailing
behind. The "raw" result of DCT is actually a doubling in size; 16 bit
coefficients are required to accurately reconstruct 8 bit samples.
However, the pattern of information allows easy compression using an
RLE/VLC approach. High compression ratios are achieved by quantising
(hence LOSSY) so that most or all trailing bits are made zero, thus
greatly improving the efficiency of RLE/VLC but also introducing
visual artifacts.
From a graphics point of view, the easiest way to understand DCT is as
a coordinate transformation in a higher dimensional space. Information
scattered throughout the original space can be made to lie adjacent to
some new principal axis in the transform space. In this way sparse
information is "gathered together", albeit at significant
computational cost.
hoff...@fho-emden.de
LordOfTh...@googlemail.com schrieb:
IMO, the chroma subsampling for each second row and each
second column (which should be executed by averaging adjacent
pixels) leads exactly to a compression of 50% - not 33% .
Half the size of the original file.
Quantization (integer division of luminance values and Cb,Cr
values, followed by rounding) leads to small numbers, which can
be effectively packed by Huffman encoding (where larger rare
numbers are not ignored). Sorting of the DCT coefficients by
frequency (ZigZag sampling) leads to (eventually) longer sequences
of zeros. Only these are packed by RLE.
http://www.fho-emden.de/~hoffmann/jpeg131200.pdf
Best regards --Gernot Hoffmann
Skybuck Flying
First I thought I had to download this special tool called MASM32.
It's some crappy installation program which crashes multiple times because
of Data Execution Protection.
Once this was disabled it installed ok.
Then I tried the Build again.
Still didn't work in Visual Studio 9.0.
Now I learn Visual Studio 9.0 already has Masm included.
Apperently there is a difference between Masm and Masm32.
The error message is:
Can't open:
Y:\C
Apperently the problem is:
Microsoft's Masm tool can't handle spaces in folders ?!?!?
Very bad shit.
Now I must install the huffman yuv video codec source code in a special
folder without spaces.
Bloody Shame !
Then I shall try again in building it.
Bye,
Skybuck.
Skybuck Flying
Now I try again, and it gets a little bit further... but now new error:
Error 1 error PRJ0019: A tool returned an error code from "Assembling
Y:\Huffyuv\huffyuv_a.asm..." huffyuv huffyuv
No idea what the problem is.
Is it a MASM problem ?
Or is it because I installed MASM32 problem ?
Hmm...
Maybe bad ASM in file.
Bye,
Skybuck.
Skybuck Flying
"
Y:\Huffyuv>"C:\Tools\Microsoft Visual Studio 9.0\VC\bin\ML" huffyuv_a.asm
Microsoft (R) Macro Assembler Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: huffyuv_a.asm
huffyuv_a.asm(526) : error A2070:invalid instruction operands
MEDIAN_PREDICT_PROC(41): Macro Called From
huffyuv_a.asm(526): Main Line Code
huffyuv_a.asm(527) : error A2070:invalid instruction operands
MEDIAN_PREDICT_PROC(41): Macro Called From
huffyuv_a.asm(527): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(7): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(8): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(17): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(98): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(101): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(103): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(7): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(8): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(17): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(98): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(101): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1001) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(103): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1001): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(7): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(8): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(17): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(89): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(90): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(93): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(94): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(7): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(8): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(17): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(89): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(90): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(93): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1002) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(94): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1002): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(7): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(8): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(17): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(98): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(101): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(103): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(7): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(8): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(17): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(98): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(101): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1003) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(103): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1003): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(7): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(8): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(17): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(89): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(90): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(93): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(94): Macro Called From
YUV2RGB_PROC(26): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(7): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(8): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(17): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(89): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(90): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(93): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1004): Main Line Code
huffyuv_a.asm(1004) : error A2070:invalid instruction operands
YUV2RGB_INNER_LOOP(94): Macro Called From
YUV2RGB_PROC(29): Macro Called From
huffyuv_a.asm(1004): Main Line Code
Y:\Huffyuv>
"
Macro problem ?
Bye,
Skybuck.
Skybuck Flying
It doesn't even seem to work on Windows X64 Pro...
Bye,
Skybuck.
Skybuck Flying
Technical details from website:
"
Huffyuv's algorithm is roughly the same as lossless JPEG: it predicts each
sample and Huffman-encodes the error. The predictor functions are "left"
(predicts the previous sample from the same channel), "gradient" (predicts
Left+Above-AboveLeft), and "median" (predicts the median of Left, Above, and
the gradient predictor). Channels are compressed separately, but in RGB mode
the channels used are actually R-G, G, and B-G. This yields much better
compression than R, G, B.
The error signal in each channel is encoded with its own Huffman table. On
compression Huffyuv picks appropriate tables from its built-in collection.
These tables are then stored in the output file and used when decompressing.
This way future versions of Huffyuv can decompress old files without my
having to explicitly support old tables. A Huffyuv-savvy application can
also specify the Huffman tables to be used for compression instead of
accepting the defaults.
"
Not sure what it all means.
Also for RGB it seems to do something different.
What is the error ?
It's all to vague.
Huffyuv 1.3.1 might be more clear.
But I am ready to give up on this analysis completely, code is crappy and
faulty.
I shall continue inspecting the yuv color space further.
And then continue with my own compression schemes ;) :D
Bye,
Skybuck.
Skybuck Flying
Like other people said.
By converting to other color space, some bits are added.
But because other color space are better compressable it could be worth it !
;) :)
Time will tell :)
Bye,
Skybuck :)
"arahne" <ara...@arahne.si> wrote in message
news:gD%Xj.12759$HS3.6...@news.siol.net...
> Dusan Peterc
> http://www.arahne.si
Frank Kotler
...
> Microsoft (R) Macro Assembler Version 9.00.21022.08
...
> Macro problem ?
Maybe. Is this a 64-bit version of Masm? If so, you may need to give it
a command line switch (no idea what) to tell it we're doing 32-bit code.
That's just a wild guess, but I've seen a similar(?) problem attempting
to assemble 32-bit code with 64-bit Gas...
Best,
Frank
Skybuck Flying
I just tested (Horizontal) Run Length Encoding using the universal coding
technique and the results are:
Lossless 24 bit RGB compresses better than
Lossless 29 bit YUV.
So 29 bit lossless YUV is just terrible !
At least when it comes to run (Horizontal) Run Length Encoding.
So it seems you were correct after all at least for RLE ;) :)
Maybe other compression techniques might work better for yuv :)
Who knows :) !?! =D
Bye,
Skybuck.
"Skybuck Flying" <Blood...@hotmail.com> wrote in message
news:8af51$48322550$541983fa$10...@cache1.tilbu1.nb.home.nl...
Skybuck Flying
It's definetly not benefitting from lossles yuv conversion.
So what could it be doing ?:
Possibilities:
1. It's doing RGB to RGB compression.
2. It's doing RGB to YUV lossy conversion and then lossless compression by
storing any additional errors if necessary.
Might work... since errors are kinda small... like 1 to 3 bits difference or
so between lossless values and lossy values mostly.
Though this still doesn't make too much sense too me... since those errors
are pretty frequent if not always present for each possible color value.
So I think it's probably doing 1.
And it must be achieving compression with something else... However I don't
believe huffman is responsible for the compression... seems unlikely.
So it must be some kind of lookup compression... like winzip uses me
thinks...
Or alternatively it determines the number of colors used in the frame and
then uses huffman on that or so... but still the huffman table would cancel
any compression achieved probably.
Bye,
Skybuck.
Skybuck Flying
I forgot an essential step in the RLE algorithm ;)
I forgot to update the Color variable lol.
I noticed it when some highly compresseable frame compressed real bad, while
it should have compressed real good.
So I shall now fix the code and test again.
Please ignore last posting.
Update will follow soon =D
Bye,
Skybuck.
Skybuck Flying
I forgot an essential step in RLE compression algorithm.
So I shall test again and then update this posting too.
Bye,
Skybuck.
Skybuck Flying
The people that had a hunch that YUV could compress better are correct.
Lossless YUV can indeed compress better than lossless RGB for most frames.
Some frames are better compressed in RGB.
It's quite impressive... but not as impressive as my Lookup method on RGB,
it achieves even more compression for the current COD4 video :)
But maybe I should try my lookup method on YUV values.
I shall try that next and see how that performs... current YUV code is more
computationally expensive though... though my lookup method is very memory
hungry too hehehehe. You'll need 32 MB of memory for it or so... yikes ! ;)
:) Worth it though :P*** ;) :P
Not sure if the speed will be good for lookup table method... maybe... time
will tell..
Let's do quick calculation:
Average access time for random memory access: 100 nano seconds.
640x480 pixels must be accessed two times for decoding in ram as extra
decode overhead.
So that's 614400 access per frame.
Multiplied by say 70 frames per second for maximum frame rate or so.
614400 * 70 = 43008000 accesses.
43008000 * 100 nanoseconds = 4300800000 / (1000 * 1000 * 1000) = 4.3 seconds
which might be too slow.
However... the little table will be in the cache mostly... so this reduces
it half memory access.. with some slight overhead which is probably
negleable. Which means 2.15 seconds. And then by simply reducing the frame
speed to 30 frames per second... Acceptable play speed of 1.075 might be
acchieved... still a bit too slow...
Ofcourse there is some other overhead too... So who knows.. the lookup table
method might be too slow... Time will tell if it can be fast enough ;) :)
And ofcourse larger video's would require more lookup... which might make it
even slower... since random access memory doesn't get any faster usually...
this might prevent the algorithm from scaling to high resolutions which
would be bad.
But for low resolutions it might be ok and good.
Bye,
Bye,
Skybuck.
Skybuck Flying
Huffman benefitting a little bit from RGB to YUV conversion...
Bye,
Skybuck.
Skybuck Flying
"
Channels are compressed separately, but in RGB mode
the channels used are actually R-G, G, and B-G. This yields much better
compression than R, G, B.
"
Hehe.
Bye,
Skybuck =D
Skybuck Flying
Now the RGB to RGB compression is working better than the RGB to YUV
compression.
Interesting :)
Bye,
Skybuck.
Frank Kotler
... but that's not it. Taking a quick look at Ben's code, it looks like
Masm's having a problem with the operands to "movd". They look okay to
me, and other versions of Masm must assemble it... Try adding "dword
ptr" and see if it helps. ("movd dword ptr [ecx], mm3" on line 466, for
starters). That's my current theory... (I don't do Masm, so I can't test
it for ya)
Best,
Frank
Skybuck Flying
Anyway I am not gonna to try that.
It's ok.
I have lost interest in this assembler code.
Bye,
Skybuck.