CorePNG - New LossLess codec

[Tommy Carrot]

Originally posted by Pamel
Sorry, let me clarify again. "Working with more original video data is better for filtering." So, if your capture card deals with YUY2 internally, and you are going to be filtering, then you should capture in YUY2. Obviously interpolating to RGB isn't going to gain you anything. But, you would loose a lot more of the original data by going doing a YUY2 --> YV12 conversion before doing your filtering.

Then imo, adding YUY2 support would make the most sense. :)

[dragongodz]

just an observation i was wondering if anyone else experienced.

playing with MediaPlayer Classic an avi using CorePNG can only be seen by me by using video output "video mixing renderer 9". if i use overlay etc then i get an error "VGA 16 colour ditherer:Xform Out" with this -

Stream 0
AVI Decompressor
Color Space Converter
VGA 16 Color Ditherer

Media Type 0:
--------------------------
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_RGB4 {E436EB79-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 50688
cbFormat: 1128

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 60825600
dwBitErrorRate: 0
AvgTimePerFrame: 400000

BITMAPINFOHEADER:
biSize: 40
biWidth: 352
biHeight: 288
biPlanes: 0
biBitCount: 4
biCompression: 7200924
biSizeImage: 50688
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 16
biClrImportant: 16


anyone else noticed this ?

[kastro68]

Originally posted by Chainmax

kastro68, what are your system specs?

The comp I use for capture is:
-Athlon 1800 = 1.54Ghz
-512mb ram
-indep. 2x Western Dig 1200JB hard disk dedicated capture drive
- OS on IBM desktar 60GXP
-leadtek winfast tv2000xp capture card
-abit kr7a-raid mainboard

[MfA]

The problem with interlaced chroma is that the chroma samples arent located where you would think they are ... you have to be carefull upsampling them. A lot of programs arent.

[Neo Neko]

I got it to compress IRT. Compression level 1, no filters, 230x240. :P And it was just under 100% CPU on my 2500+ Athlon Barton.

[jcsston]

I've added some YUV2 en/decoding support. It does support YV12, but decoding for YV12 is currently non-working.
CorePNG v0.7 VFW Codec (http://corecodec.org/project/showfiles.php?group_id=39)

scharfis_brain, Mfa: If I get YV12 input should I assume it is interlaced? or is there any way to tell without user input?

dragongodz: What color-depth are you running at? I don't convert between too many colorspaces/depths yet, so if your display bit-depth doesn't match the clip bit-depth you could have problems.

kastro68, Neo Neko: Delta-frames increase the cpu power needed a good deal, and Auto-Delta frames almost doubles it (or it should) The new YUY2 en/decoding is faster than RGB ;)

For SMP it may be some more time, after trying to implement it I found it was more work than I had first thought.

[Koepi]

jcsston:

well, you could solve it like ffvfw does:
a) a checkbox which tells to use this or not
b) the option to check with that will be "assume interlaced when > [XXX] lines"

So you would be able to switch interlace support off, and you could switch between PAL and NTSC world.

I find that solution very handy. You could also add just a "interlaced" checkbox if i think about it.

Best regards
Koepi

[scharfis_brain]

I've got a "CorePNG_vfw.dll not found" - error, when trying to install it on my win98-PC. Everytime the dialog to set the direcory of CorePNG popped up, but Windoze never found it.

After a while I renamed CorePNG_vfw.dll and CorePNG_vfw.inf to just CorePNG.dll (the inf, too) and edited every "_vfw" in the inf away. After this procedure, Win98 let me install the Codec.

[Mug Funky]

@scharfis_brain:

that's interesting... maybe win98 doesn't like it's system files to be in anything other than 8.3 filenames?

heh. i'm kinda glad i don't use it anymore. i measure win2k performance in "crashes per year" rather than "crashes per hour" for win95/98...

[Tommy Carrot]

I've tried the new version. There is no option to selecting colorspaces, so i'm assuming it's using YUY2 instead of RGB. Is this right?

Btw, i've made a little test with anime, with the following settings. FFV1 used arithmetic coding, and every frame was keyframe. CorePNG used compression level 9, auto delta frames, and all filters on. The results:

ffv1: 434M
CPNG: 391M

Nice work! The delta frames do wonders!

But the some optimization wouldn't be bad. The ffv1 took 6m20s, while CPNG took 1h22m! :eek: Especially enabling all the png compression filters does heavy performance hit.

[Atamido]

Originally posted by Tommy Carrot
ffv1: 434M
CPNG: 391M Thats not bad considering FFV1 works in YV12 which has less data than the YUY2 that CorePNG is using. On my Simpsons clip the space went down to 32,016KB, which is a 20% improvement in space. If jcsston gets YV12 working then it will likely be about a 34% space improvement over RGB. It would kick the trash out of any other lossless codec in anime type video.

Unfortunately there are not a lot of speed improvements to be made without rewriting parts of libpng.

BTW, anyone else have a problem with explorer dying if you click on a file encoded to YUY2 with CorePNG?

[MfA]

The advantage if FFV1 is that the encoder structure is straightforward, optimization is a snap. PNG is complex as hell.

You dont really have to worry much about interlacing as long as you dont do colorspace conversion, just add a mode to split frames into fields and do seperate field encoding ... you might want to make the decision dynamic just like the delta coding, since wether splitting it up helps or hurts depends on the amount of motion.

[dragongodz]

jcsston - i tried both 16bit and 32bit screen colours. doesnt matter since it appears to be fixed with version 0.7. plays with output to overlay fine now. :)

[Kurosu]

Originally posted by Tommy Carrot
Btw, i've made a little test with anime, with the following settings. FFV1 used arithmetic coding, and every frame was keyframe. CorePNG used compression level 9, auto delta frames, and all filters on. The results:

ffv1: 434M
CPNG: 391M
The comparison isn't really fair. The most space gain is by removing most temporal correlation (even with such a method as delta-frames), ie not encoding every frame as a key frame. And anime is sure something where there is a high duplicate count.

I don't recall the setting name in FFV1, but what about trying to set a key frame every 60 frames (2s) so as to have a usable content (ie which doesn't take ages to skip to a frame) ?

[Tommy Carrot]

Originally posted by Kurosu
The comparison isn't really fair. The most space gain is by removing most temporal correlation (even with such a method as delta-frames), ie not encoding every frame as a key frame. And anime is sure something where there is a high duplicate count.

I don't recall the setting name in FFV1, but what about trying to set a key frame every 60 frames (2s) so as to have a usable content (ie which doesn't take ages to skip to a frame) ?

That's true, but the size gain of ffv1 is minimal with delta-frames (a couple MB), it uses another method for them, not so good for animes, but better for movies.

[Atamido]

Well, I decided to encode all of that one Simpson's episode to get a more accurate comparison. I set the video to Fast Recompress to preserve the YV12 colorspace. This let me get a more accurate compression comparison accross the board. I'm using a build of CorePNG that 'supports' YV12.S03E17 - 8F13 Homer at the Bat
512x384 pixels
1379.922 seconds
33085 frames
108MB
DivX 311
No audio

Size:
4,744MB Huffyuv* v2.1.1 - CCESP Patch v0.2.3
3,061MB VBLE (beta version)
2,812MB Loco v0.2
2,318MB FFV1 Plane w/ Delta frames Sep 27, 2003
1,312MB CorePNG Best Auto-Delta v0.7 vfw

Compression Time:
10 minutes Huffyuv
10 minutes VBLE
17 minutes Loco
20 minutes FFV1
328 minutes CorePNG

Comparative Time/Space Efficiency:
(Lowest time/Time)x(Smallest size/size)x100
27 Huffyuv
42 VBLE
27 Loco
28 FFV1
03 CorePNGNothing very new here except more proof that CorePNG will compress anime losslessly with better compression than any other codec. It is also slower than any other codec, making it ideal for long term storage of lossless data and for clips needing an alpha channel.

This was compressed using an Athlon 2100+. By these numbers you would need the equivalent of an Athlon 30000+ to capture in realtime at 512x384 with CorePNG.

These numbers could fluctuate some with others numbers because the process priority was set to BelowNormal. Defrag was also running on a seperate partition. While nothing was using much CPU during the initial portion of encode, it is possible that CPU usage could have spiked during any of the performed jobs.

*I believe that Huffyuv can only do YUY2 and so has to upsample the colorspace, making it larger.

[winman]

Heh, can't wait until AMD release the Athlon 30000+ :) Hopefully the codec will fully support SMP before that.

Originally posted by Pamel
*I believe that Huffyuv can only do YUY2 and so has to upsample the colorspace, making it larger. [/B]

If you select the HuffYUV encoder that come with ffvfw (Sep 27, 2003), you can choose the colorspace of YV12 or YUY2.

[General Lee D. Mented]

Originally posted by Pamel
Nothing very new here except more proof that CorePNG will compress anime losslessly with better compression than any other codec. It is also slower than any other codec, making it ideal for long term storage of lossless data and for clips needing an alpha channel.

I believe CorePNG's anime performance may be further improved by changing the simple left->right 1 line at a time scanorder to a fractal scan. It's possible to do this transparently by using a function to generate a scan order based on the video resolution, so the order can be reproduced on decode without storing any new information. I suggest something fairly simple like a quadrant division fractal. I haven't looked at CorePNG source yet (I hear it has some interesting VFW source :) ) but I could probably build that in if you wanted. Or at least give jcsston the functions. Also, PNG spec defines several filter modes for pixel prediction. Any idea which one is being used in these tests if any?

[ChristianHJW]

Originally posted by General Lee D. Mented I suggest something fairly simple like a quadrant division fractal. I haven't looked at CorePNG source yet (I hear it has some interesting VFW source :) ) but I could probably build that in if you wanted.

GLDM, this sounds really interesting ! CorePNG is pretty slow right now, so if it could achive a better compression then even now, i am sure many users would be allright with that, as long as they can losslessly compress their stuff .... how long would it take you ?

[Kurosu]

Originally posted by Pamel
It is also slower than any other codec, making it ideal for long term storage of lossless data and for clips needing an alpha channel.
Indeed, as:
- FFV1 is still considered not mature/frozen
- VBLE is beta, and more important, no source code for decoder is available

[General Lee D. Mented]

Originally posted by ChristianHJW
GLDM, this sounds really interesting ! CorePNG is pretty slow right now, so if it could achive a better compression then even now, i am sure many users would be allright with that, as long as they can losslessly compress their stuff .... how long would it take you ?

Jcsston had something running last night after I discussed it on #matroska and gave him some functions, but it didn't work well. I analyzed the image he produced, and I think he just did it backwards. I.e. he took a linear read of the source, and stored it fractally in the target, whereas the idea was to read the source fractally and store it linearly in the target, since PNG compresses in a linear fashion along scanlines. I think he wandered off and I had to go to sleep so I dunno if he's fixed it since then.

[jcsston]

I fixed the YV12 encoding and decoding, in CorePNG VFW Codec v0.8 (http://corecodec.org/project/showfiles.php?group_id=39).
I now use the asm optimized versions of zlib and libpng. Which gave it a little speed boast :)

CorePNG Best 300 Auto-Delta frames
YUY2 320x240 752 frames
no asm
27:16
asm
21:40
On an Althon 650mhz.

I've also added a status dialog so you can see what colorspace it is encoding in.

[General Lee D. Mented]

Originally posted by jcsston
I fixed the YV12 encoding and decoding, in CorePNG VFW Codec v0.8 (http://corecodec.org/project/showfiles.php?group_id=39).
I now use the asm optimized versions of zlib and libpng. Which gave it a little speed boast :)

CorePNG Best 300 Auto-Delta frames
YUY2 320x240 752 frames
no asm
27:16
asm
21:40
On an Althon 650mhz.

I've also added a status dialog so you can see what colorspace it is encoding in.

I still can't figure out why the scan is sucking though. Maybe because it was interleaved RGB?

[zettai]

Is RGB compression broken in 0.8?

I'm getting error code -100 in vdubmod using RGB modes when recompressing a huffyrgb24. If you want a crash dump, let me know and I'll email you one.

[MfA]

GLDM, why not try out the hilbert scan in FFV1? (I assume you are using that scan, it is generally considered to be the best.) If that works then it wouldnt be too hard to experiment with wavelets too in the same framework, CABAC is a lot speedier than BWT ...

A possible explanation of why raster order scanning could work better can be found here (http://citeseer.nj.nec.com/283576.html).

[jcsston]

Originally posted by zettai
Is RGB compression broken in 0.8?

I'm getting error code -100 in vdubmod using RGB modes when recompressing a huffyrgb24. If you want a crash dump, let me know and I'll email you one.
I was so focused on YUV support I forgot to check if all RGB encoding options worked. The RGB Delta-frames were broken. It's fixed in v0.8.1 (http://corecodec.org/project/showfiles.php?group_id=39).
I also fixed a bug that would prevent loading under Win9x.

[Chainmax]

Will General Lee D. Mented's suggestion yield better results for normal footage or just for anime?

[MfA]

TheXung, are you still planning on releasing a JPEG-LS/LOCO-I based codec BTW?

[TheXung]

Originally posted by MfA
TheXung, are you still planning on releasing a JPEG-LS/LOCO-I based codec BTW?

That's a question that I don't know the answer to because I tend to start on lots of different things and don't finish a lot of them. Or I come up with ideas that I don't even get around to (especially given that I don't do video captures and have never needed a lossless codec). Any major development though will occur after mid December.

Anyone who is just hungry to do lossless codec development, I truly believe that the most practical solution to a capturing codec is a refined loco based one. It teeters on the border of just being complex/simple enough to be able to capture at full resolution in real time. Computers aren't going to get that much faster in the next couple years. And it is a better algorithm than PNG. I repeat, it is a better algorithm than PNG.

[BetaBoy]

CoreLOCO? :D

[MfA]

LOCO-I in it's original form wont work all that well for anime ... so if anyone feels adventurous and wants to host a LOCO-I based codec on CoreCodec Id call it CorePURE or something, in the end it will probably be pretty heavily modified anyway.

It would be very little work to take one of the existing open source JPEG-LS implementations (there are plenty, and JPEG-LS <=> LOCO-I) and hack it into CorePNG.

[General Lee D. Mented]

Originally posted by MfA
GLDM, why not try out the hilbert scan in FFV1? (I assume you are using that scan, it is generally considered to be the best.) If that works then it wouldnt be too hard to experiment with wavelets too in the same framework, CABAC is a lot speedier than BWT ...

A possible explanation of why raster order scanning could work better can be found here (http://citeseer.nj.nec.com/283576.html).

Actually WARP's scanmatrix was using a hilbert or peano scan (websites don't seem to agree often on which is which), but after some research I found that a recursive quadrant scan like hilbert but without the rotations should work better in most cases, because the lack of rotation means a higher probability of getting matching sequences of symbols. It's also much simpler to code, especially as the number of dimensions of the scan space increases (not an issue here but believe me doing a 3D hilbert for a hologram is annoying to write, even the 2D one was irritating).

So, the scan I gave jccston was this quadrantscan, which is basicly a rotationless hilbert. He reported that zipping a bmp usually produced better compession using my scan, but a png of both images usually produced better compression on the standard (raster) scan. Which leads me to suspect that png has some optimizations that take things like horizontal resolution into account before calling zlib.

[MfA]

Which filter-type (http://www.libpng.org/pub/png/spec/1.2/PNG-Filters.html) does CorePNG use?

[Marc FD]

huhu a new lossless codec. fun because i started again to play with that a few days ago ^^.

and to be honest i don't see how zlib compression on images could be _that_ good ^^;;

seems there is a yv12 version, i eager to try it out. ^^

we'll soon see if CorePNG outperform both a unrestricted huffyuv in yv12 and a little guy's (me) poor-man's compression lossless stuff =)

EDIT : CoreCodec.org seems down here in france T_T... could s.o. attach the last working yv12 version please :)

[jcsston]

Originally posted by MfA
Which filter-type (http://www.libpng.org/pub/png/spec/1.2/PNG-Filters.html) does CorePNG use?
It uses all of them, I believe libpng adaptively chooses which to use depending on the first row of the image.
You can choose in the codec options which filters will be enabled and used or if any at all will be used.

and to be honest i don't see how zlib compression on images could be _that_ good ^^;;
zlib compression is only half of PNG, a good deal of the compression comes from the filters too.

CoreCodec.org seems down here in france T_T... could s.o. attach the last working yv12 version please :)
I put up a mirror here (http://webjory.tripod.com/corepng/) until cc.org is back up and running.

[MfA]

Filters 2-4 will access irrelevant values with the hilbert scan right?

[Marc FD]

hum, isn't impressive in yv12.

some % under vble & huffyuv (3-5%), but much more than 10x slower ^^;

but the test clip i use for lossless coding is a very hard one, even video codecs don't compress it much ^^.

[TheXung]

Originally posted by MfA
LOCO-I in it's original form wont work all that well for anime ... so if anyone feels adventurous and wants to host a LOCO-I based codec on CoreCodec Id call it CorePURE or something, in the end it will probably be pretty heavily modified anyway.

I dunno about that. Some of my testing shows that on keyframes, JPEG-LS wins hands down:

first number is the jpeg-ls, second is the png

frame from akira:
226k/240k

frames from simpsons:
262k/291k
343k/399k
260k/296k

though the sources for the test were from divx encodes so there is artifacting in there. And this is using adaptive filtering for png

[MfA]

With synthetic sources with large evenly coloured surfaces JPEG-LS is often outperformed, I guess there usually is too much noise for that to be an issue though.

[BoNz1]

Wow, what a coincidence. It appears that JPEG-LS was developed at my university. If you like I may be able to track down the people who wrote this and direct them to you if you are interested in writting an encoder.

[General Lee D. Mented]

Originally posted by MfA
Filters 2-4 will access irrelevant values with the hilbert scan right?

2 and 4 should be irrelevant, as the vertical construction of the image is destroyed. However, I'd expect filters 1 and 3 to perform better. I tried enabling and disabling filters and even using none, but still always got bad results with the quadrant scan.

Here's a couple examples to play with if you like:

http://www.gldm.net/orig.png
http://www.gldm.net/quadrant.png

and the function, if anyone wants to play with that too:


void QuadrantScan(int** order, int hmin, int vmin,
int hmax, int vmax, int size, int &current)
{

int hmintemp, vmintemp, hmaxtemp, vmaxtemp;

if (size == 1) // 1x1 array
if(order[vmin][hmin] != 0)
{
order[vmin][hmin] = current; // store order seen
current++;
}
else
; // don't store if marked out
else{
size /= 2;

hmintemp = hmin;
vmintemp = vmin;
hmaxtemp = hmax - size;
vmaxtemp = vmax - size;
QuadrantScan(order, hmintemp, vmintemp,
hmaxtemp, vmaxtemp, size, current);

hmintemp = hmin;
vmintemp = vmin + size;
hmaxtemp = hmax - size;
vmaxtemp = vmax;
QuadrantScan(order, hmintemp, vmintemp,
hmaxtemp, vmaxtemp, size, current);

hmintemp = hmin + size;
vmintemp = vmin + size;
hmaxtemp = hmax;
vmaxtemp = vmax;
QuadrantScan(order, hmintemp, vmintemp,
hmaxtemp, vmaxtemp, size, current);

hmintemp = hmin + size;
vmintemp = vmin;
hmaxtemp = hmax;
vmaxtemp = vmax - size;
QuadrantScan(order, hmintemp, vmintemp,
hmaxtemp, vmaxtemp, size, current);

}

return;
}


How to use it:
int** order is a 2D array of ints initialized to 1s used as a lookup table, to know what linear order a given 2D pixel falls in. Note that the array must be SQUARE and POWER of 2. Note int size is the length of the SIDE of the square array, not is entire area. If you need to handle cases with non-square areas or anything that doesn't fit perfect, load 1s in the area you plan to use, and 0s in the area you want masked out. For example, on a 512x512 array, if your image is 512x384, fill the first 384 lines with 1s, and the last 128 with 0s to generate a proper lookup table. This works for any pixel mask including random.

Once the table is made, forward transform looks like this:

destination[order[i][j]] = source[i][j];

reverse transform:

destination[i][j] = source[order[i][j]];

Note the 2D->1D translation by the table. If you want 2D->2D or some other combintation I'll leave the / and % conversion of 2D coordinates to and from a linear index for your own coding fun.

[TheXung]

Originally posted by MfA
With synthetic sources with large evenly coloured surfaces JPEG-LS is often outperformed, I guess there usually is too much noise for that to be an issue though.

I've yet to implement PNG but what exactly does it have over JPEG-LS that makes it so good for large evenly coloured surfaces? I mean, JPEG-LS does have a run-mode that should do just that (which by the way, I also haven't found code for in the LOCO 0.4 codec).


GLDM, that sure is a fancy scan you got going. However wouldn't a scan that makes objects only a pixel tall have a negative effect on prediction accuracy?

[General Lee D. Mented]

Originally posted by TheXung
I've yet to implement PNG but what exactly does it have over JPEG-LS that makes it so good for large evenly coloured surfaces? I mean, JPEG-LS does have a run-mode that should do just that (which by the way, I also haven't found code for in the LOCO 0.4 codec).


GLDM, that sure is a fancy scan you got going. However wouldn't a scan that makes objects only a pixel tall have a negative effect on prediction accuracy?

I'm not sure, there might be something in that paper MFA linked to. I looked through it, but didn't understand alot of the math parts.

The scan looks fancy but it's really a simple idea. You just take a square, and divide it into 4 parts. Then divide each of those into 4 parts, until your squares are only 1 pixel big. Then as the recursive functions return, they each assign a square a number in the order that they return. The hilbert and peano space-filling curves do the same, except in their scan each subdivision can be a rotation (90/-90/180 degrees) of the order of the caller. Mine always uses the same order at every level so it's more likely to produce the same results for similar features in the image.

What this does is produce a scan order that gives you a 1x1 pixel, surrounded by its neighbors that compose a 2x2 square, surrounded by 3 other 2x2s to make a 4x4, then an 8x8, 16x16, etc. This way, when you compress the resulting stream of pixels, large areas of similar color should be all next to each other in a line. Which I would think would be easier to compress but apparently not.

[Marc FD]

finished my stuff. it's funny because it looks a lot like LOCO-I, (well it's less complex) but i didn't have read anything about LOCO when i designed the algo. i had only tested felics (which behaved bad but gave me good ideas)

tested in yv12, it compress more than the corePNG codec (about -10%) and is 2.5x faster. (iframes only coding)

still plain C and lazily optimised.

i'll do some asm-ing, to see how fast it could be ^^.

btw, sorry if you feel i hijack the thread, i'd like to keep clear it's not my intention at all, just the discution seemed to turn around lossless coding so ... ^^

[zettai]

MarC, can you please include RGB24, 32 and YUY2 modes as well? It's great having a lossless codec but if you are developing video in RGB it's no fun having to have a lossy colour conversion :)

[MfA]

I think the dictionary based coding is better at representing reoccuring long runs of the same color. A 2D oriented RLE can help here.

For truly synthetic images there are also dither patterns which dictionary based coding can deal better with, and gradients which can be perfectly predicted. Having long strings of perfectly predicted pixels isnt a good case for JPEG-LS, if you wanted to support near lossless coding you would really want to fix that too.

GLDM, if you do that to the pattern it is no longer a continuous curve ... I dont think that is a good idea.

[General Lee D. Mented]

Originally posted by MfA
I think the dictionary based coding is better at representing reoccuring long runs of the same color. A 2D oriented RLE can help here.

For truly synthetic images there are also dither patterns which dictionary based coding can deal better with, and gradients which can be perfectly predicted. Having long strings of perfectly predicted pixels isnt a good case for JPEG-LS, if you wanted to support near lossless coding you would really want to fix that too.

GLDM, if you do that to the pattern it is no longer a continuous curve ... I dont think that is a good idea.

The continuous curve is a nice mathematical concept, but when applied to a 2D field of discrete pixels it's kinda pointless to maintain continuity since the pixels are discrete anyway. The main reason hilbert is used in scans is because of how it converts 2D locality to 1D locality. i.e. the scan traverses pixels in an ever widening area without jumping to a distant pixel like a scanline does at the end, and I preserved that property. I mean sure if it was continuous the last pixel of the current block would be next to the first pixel of the subsequent block, but I don't think that's going to produce a significant benefit. The only case where it does is when the trans-block boundary of the level you're on is predictable in the direction the curve is moving at that time. I think you'll lose more in efficieny because your scan order of a given block is constantly rotating, so if you had say, an 8x8 macroblock with 2 identical 4 pixel objects it you won't usually get the same pixel order and hence it won't be predictable.

There's situations in which either algorithm has advantages and disadvantages.

[esby]

I'm having trouble to access the website associated with the codec.

Can someone confirme if the site is down until further notice,
or if it should be back up in time or somewhere else?
(--> how i get the codec :))

esby

[Atamido]

Originally posted by General Lee D. Mented
Here's a couple examples to play with if you like:

http://www.gldm.net/orig.png
http://www.gldm.net/quadrant.png I honestly would have suspected that PNG would have compressed the quadrant picture better because of the way that colors are isolated to lines, but apparently my understanding of it is to short. This picture actually compresses far worse if turned verticaly, but this is not always the case. I tried to get jcsston to add an option where the image would be rotated 90 degrees and recompressed to see if it got any smaller, but he didn't want to. I guess increasing encoding/decoding time for such a marginal improvement in encoding size wasn't a priority. :p

[jcsston]

Originally posted by esby
I'm having trouble to access the website associated with the codec.

Can someone confirme if the site is down until further notice,
or if it should be back up in time or somewhere else?
(--> how i get the codec :))

esby
I put up a mirror here (http://webjory.tripod.com/corepng/) until corecodec.org is back up and running.

I guess increasing encoding/decoding time for such a marginal improvement in encoding size wasn't a priority.
In my tests it didn't make any difference in size with rotating.