Education Forums
| View previous topic :: View next topic |
| Author |
Message |
Skybuck Flying
Guest
|
 Posted: Sun May 18, 2008 12:25 am Post subject: Which color space would be best for lossless compression pur |
 |
|
Hello,
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. |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Skybuck Flying
Guest
|
| Posted: Sun May 18, 2008 7:08 am Post subject: Re: Which color space would be best for lossless compression |
|
|
For compression purposes it might be possible to create a specific color
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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
arahne
Guest
|
| Posted: Mon May 19, 2008 12:47 am Post subject: Re: Which color space would be best for lossless compression |
|
|
Skybuck Flying wrote:
| Quote: |
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 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Thomas Richter
Guest
|
| Posted: Mon May 19, 2008 11:01 am Post subject: Re: Which color space would be best for lossless compression |
|
|
Skybuck Flying schrieb:
| Quote: |
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?
| Quote: |
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.
| Quote: |
2. Sliding Window Color Lookup with smaller index. (Good when many repeting
colors near each other)
|
What is that?
| Quote: |
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 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Skybuck Flying
Guest
|
| Posted: Mon May 19, 2008 11:01 am Post subject: Re: Which color space would be best for lossless compression |
|
|
I want to understand why HuffmanYUV codec achieves 50% compression.
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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Skybuck Flying
Guest
|
| Posted: Mon May 19, 2008 11:01 am Post subject: Re: Which color space would be best for lossless compression |
|
|
The shitty thing is I can not build the HuffmanYUV 2.1.1 codec because it
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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Mon May 19, 2008 3:30 pm Post subject: Re: Which color space would be best for lossless compression |
|
|
On May 19, 11:13 am, "Skybuck Flying" <BloodySh...@hotmail.com> wrote:
| Quote: |
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.
| Quote: |
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. |
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Mon May 19, 2008 3:47 pm Post subject: Re: Which color space would be best for lossless compression |
|
|
LordOfTh...@googlemail.com schrieb:
| Quote: |
On May 19, 11:13 am, "Skybuck Flying" <BloodySh...@hotmail.com> wrote:
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.
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
http://www.fho-emden.de/~hoffmann/jpeg131200.pdf
Best regards --Gernot Hoffmann |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Mon May 19, 2008 3:54 pm Post subject: Re: Which color space would be best for lossless compression |
|
|
LordOfTh...@googlemail.com schrieb:
| Quote: |
On May 19, 11:13 am, "Skybuck Flying" <BloodySh...@hotmail.com> wrote:
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.
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 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Thomas Richter
Guest
|
| Posted: Mon May 19, 2008 7:16 pm Post subject: Re: Which color space would be best for lossless compression |
|
|
Skybuck Flying schrieb:
| Quote: |
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.
| Quote: |
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 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Skybuck Flying
Guest
|
| Posted: Tue May 20, 2008 5:27 am Post subject: Re: Which color space would be best for lossless compression |
|
|
Hmm.
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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Skybuck Flying
Guest
|
| Posted: Tue May 20, 2008 5:29 am Post subject: Re: Which color space would be best for lossless compression |
|
|
Ok,
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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Skybuck Flying
Guest
|
| Posted: Tue May 20, 2008 5:36 am Post subject: Re: Which color space would be best for lossless compression |
|
|
I try compiling from command line:
"
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( : 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(9: 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(: 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(9: 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(: 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(: 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(: 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(9: 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(: 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(9: 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(: 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(: 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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Skybuck Flying
Guest
|
| Posted: Tue May 20, 2008 5:42 am Post subject: Re: Which color space would be best for lossless compression |
|
|
I also tried the MASM32 editor.
It doesn't even seem to work on Windows X64 Pro...
Bye,
Skybuck. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Skybuck Flying
Guest
|
| Posted: Tue May 20, 2008 5:54 am Post subject: Re: Which color space would be best for lossless compression |
|
|
I give up on huffyuv 2.1.1 it's crap.
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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
93 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
