Prev: No lock for bt instruction ?
Next: ~~~ LATEST TECHNOLOGY~~~ click here
From: Skybuck Flying on 20 May 2010 16:57
Yeah good point...

This posting of yours just gave me an idea :)

I already did some modest form of horizontal/vertical and even diagonal
compression and frame compression and a mixed of all this... but just for 8
bits at a time...

I was wondering if vertical RLE would be possible... first I was thinking
along the lines of multiple vertical lines...

But I just realized it should be possible to do a simple vertical RLE which
simply skips over the "horizontal line width" and then perhaps wraps around
to the next vertical line + 1 or so... I am not sure what the algorithm
would be, but it would probably need a second loop... so I guess it would
simply be the familiar
for x
for y loop ;)

However there is a "little/big" problem with this.

I want a really fast codec... so I was thinking about simply hard-coding one
method and ignoring the other one...

So the codec would always use horizontal RLE...

But I can imagine some scenes/frames where vertical RLE... would give much
better compression...

I do wonder what the memory performance would be for RLE since there would
probably (?) be big skips... and less streaming/cache usage ?

I did have some idea's to do quick scan for some other compression
algorithms... but for RLE I don't know if some sort of fast scan could be
done... maybe try a few lines or so ?

But RLE is presumeably so fast it probably won't hurt that much to do it
vertical and horizontal and then select the best one... and maybe even
especially when gpgpu is used... which still needs to be investigated by
me...

I am not sure if nvidia's CG dll will run on ATI cards ? I think so but not
sure... never tested it so far...

And you correct about the compressed files... I see the same happen with the
harddisk.

The harddisk is limited to 60 MByte/sec or so... so the frames must all fit
in 60 MByte/sec or less... otherwise the harddisk is not fast enough...

The CPU is much faster than just 60 MByte/sec ! ;) :) so it can decompress
it...

I think I could probably re-use my existing class and simply add a boolean
to switch modes and try... this will prevent namespace pollution and issue's
so it could look like:

..CompressionDirection := cd_horizontal;
or
..CompressionDirection := cd_vertical;

Something like that it could be called.. ;) :)

"MitchAlsup" <MitchAlsup(a)aol.com> wrote in message
news:f51799f2-a814-45c8-855d-105a78d64680(a)c7g2000vbc.googlegroups.com...
>I once wrote a comperssioni algorithm that would take vectors for a
> VLSI tester and compress these. It ends up that when one looks at the
> vectors there is very little change in the vertical direction, and
> much change in the horizontal direction.
>
> RLE in the horizontal direction got 40%-ish lossless compression
> RLE in the vertical direction vas getting 99.3% lossless compression
>
> The compression was so good, it was actually faster to read out these
> multi-GByte files into the tester in compressed form and expand them
> on the fly into the tester than to read the image directly off the
> disk.
>
> Moral: compress on the dimension that has commonality.
>
> Mitch

Bye,
Skybuck and thanks for responding ! =D


From: Skybuck Flying on 20 May 2010 22:59
> I think I could probably re-use my existing class and simply add a boolean
> to switch modes and try... this will prevent namespace pollution and
> issue's so it could look like:
>
> .CompressionDirection := cd_horizontal;
> or
> .CompressionDirection := cd_vertical;
>
> Something like that it could be called.. ;) :)

Right before I wanted to go to bed I had another idea for the name:

..RunningDirection := rd_horizontal;

or

..RunningDirection := rd_vertical;

Or perhaps better to indicate a single state of being/to-be:

..RunDirection := ... etc;

However it's kinda funny/interesting that .RunningDirection could actually
be changed while the algorithm runs...

Then it could start behaving like a worm... or a hook.

It could perhaps use 2 bits to indicate what new direction it went into...
or perhaps one bit... or perhaps even no bits !

The algorithm could start with a horizontal run... and then when it can't go
any further it could try to go always down to see if it can run further
there...

The decoder would then know this as well... this would need no bits... but
it would require ofcourse a new count... but just a new count only... no
extra color information...

After this strange deviation is done... the algorithm could go back to the
point of deviation and continue as normal... it could use a bitset to keep
track of what pixels where already compressed by the "strange" worm like
creature ;) :) and skip those...

Kinda funny algorithm... I might try it out to see what it gives... it could
be interesting for for example "box like structures"... for example gui
video's could have such boxes...

In that case the worm could even maintain a steady order of going about for
example:

First right, then down, then left, then up again... the algorithm could keep
track of the counts to make sure it doesn't enter it's previous trail...

Such a compression algorithm could be nice for square like spirals or so...
though I would not expect too many video's to have those...

But other line-structures are thinkable were this might work...

Though this could get a little bit out of hand... and the remaining question
would then be when to stop ?

Perhaps after it can't go into the next direction... or maybe it could give
the direction after that a try... but no it can't do that because then it
would backtrack funny enough...

So the answer is pretty apperent... if it can't go into the next direction
then it must stop... ofcourse the bitset could help as well to detect
collisions... and perhaps move into another direction... possibly even
against the general rules of going right... it could now go left to try
something different or so... kinda funny.

However if it followed legal counts then it would go right as long as no
bitset is crossed.

This is kinda experimental idea though... and the bitset would require a lot
of random access and a lot of extra overhead... so I will probably not do
that for now... since I want to get something done and working ! ;) :)

So I guess turning on my PC just to post this message was a little bit worth
it after all since I did not plan to write this possible extension to the
algorithm... but there ya go ! ;) Conclusion: One never knows what you might
end up with once you start to write your thoughts down on "virtual paper" ;)
:) At least that's the case with me... it happens very often... I guess one
could say: "I am an ideas-drifter" ;) :)

Bye,
Skybuck =D


From: Skybuck Flying on 20 May 2010 23:01
Hmmm... this could actually be quite an interesting idea, since this could
be applied to 3D volumes as well ?! ;) :)

So little extra note there ! ;) :)

Bye,
Skybuck =D


From: Skybuck Flying on 21 May 2010 08:21
Ok,

Me just woke up after a good 10 hours night sleep, I like that !, Me happy
about that ! =D

Anyway...

I have now three new idea's to try out:

1. RunningDirection := RD_CHOOSE;

2. RunningDirection := RD_BOTH;

3. RunningDirection := RD_WORM;

The most interesting two are probably 1 and 3... number 2 I just made up ;)
:)

Number 1 would choose which direction is the best at each new runlength.
Number 2 could try to go in both directions as the same time... which is
kinda interesting to try out as well.
Number 3 seems most interesting where the worm can have two decision
directions of each end of a run.

All these methods require relatively a little ammount of bits to add after
each encoding.

I think it's worth investigating how much better or worse compression these
methods might give.

All these methods would probably use a bitset at the encoder and decoder to
keep track of pixels/color components which were already compressed.

So the bitset/bitget functions would be very important to be fast...
unfortunately... Delphi 2007 can't inline assembler routines so there would
be quite some procedure call overhead and return :( But for now this
will/would have to do.... very maybe it might be possible to inline the asm
instruction myself with an
asm

endl
statement block... but this is probably a bit tricky to do but I think I
know a way... just loading the variables into some register might work ? but
what if those registers are already being used by the code ? hmm... maybe a
push and pop ? But then maybe a routine call might be just as fast... me not
sure about that.
Anyway it is interesting for compression wise... speed wise... I don't
know...

Alternatively an array of bytes instead of bits could be used to see if
maybe an array of bytes is faster... it would use up more bandwidth
probably... but if there is plenty of bandwidth on the pc than at least on
pc not a problem... Using bytes might actually allow encoding more decision
information or so for the algorithm... as long as the decoder does the
same... for now I have no idea how to add extra information... for now it's
simply... compressed or not compressed ;) :)

There I will leave my descriptions of these algorithms at that ! ;) :)

Bye,
Skybuck :)



First  |  Prev  | 
Pages: 1 2 3 4
Prev: No lock for bt instruction ?
Next: ~~~ LATEST TECHNOLOGY~~~ click here