CorePNG - New LossLess codec

[Atamido]

Here is a new lossless codec based on PNG developed by the talented jcsston. Essentially, each frame is compressed as a PNG, so if PNG does it, this codec does too. (RGBA) This new version has the ability to write P frames and to autodetect when it should. The P frame takes the difference of the previous frame and the current frame and encodes that as a PNG.

Things to note:
1. It is slower to encode than Huffyuv.
2. It is usually slower to decode than Huffyuv.
3. File sizes are usually smaller than Huffyuv.
4. It works best with large areas of similar color like Anime/cartoons.
5. P frames take a little more power to decode because the codec must take the difference of the video after decoding the frame.
6. Encoding with Auto-Delta frames is about 50% slower because it must encode each frame twice.
7. There is a maximum interval of 1000 frames between keyframes.

Here it is:
CorePNG vfw (http://corecodec.org/project/showfiles.php?group_id=39)


This really shouldn't be sitting at the bottom of another thread. Actual stats will be posted next.

[Koepi]

Nice work Pamel! :)

Is there any chance to make that codec/PNG YUV-aware? As far as i understand it, PNG uses more or less some kind of zip/gz compression, so it shouldn't be too problematic to feed it with "any" kind of data. (I'm of course aware that there are libgz-based codecs [ok, I know of one slow one] out there, but PNG is somewhat inherantly more graphics/image based.)

Anyways, thanks for your time spent on it and for your work!

regards
Koepi

[Atamido]

Whoa there speedy! This codec is ALL jcsston. I just told him to do it. ;)

Here are some test clips to show how well certain things work. (all tests were done in RGB)

01:47.265 - 02:18.472 S03E17 - 8F13 Homer at the Bat
512x384 pixels
31.44 seconds
752 frames
No audio

158,184KB Huffyuv
131,190KB Loco
130,582KB All I frames Fastest
113,192KB All I frames Normal
109,812KB All I frames Best
73,654KB 2 P frames Normal
61,868KB 100 P frames Fastest
50,369KB 100 P frames Normal
49,189KB 100 P frames Best
40,603KB 1000 P frames Best with Auto-Delta frames


StarwarsAAC5_1anamorphicXviD.mkv From the Anamorphic test.
720x432 pixels
32.60 seconds
815 frames
No audio

311,895KB Huffyuv
325,213KB All I frames Normal
276,710KB 1000 P frames Best with Auto-Delta frames


3 Blocks, Simple rendered scene.
320x240 pixels
10.00 seconds
240 frames
No audio

14,903KB Huffyuv
2,785KB All I frames Normal
2,538KB 1000 P frames Best with Auto-Delta frames Encoding to "All I frames Normal" is about 4-5 times slower than encoding to Huffyuv. Encoding to "Best" is about 4 times slower than "All I frames Normal". Encoding to "Fastest" is about twice as fast as "All I frames Normal". And using Auto-Delta makes the encode take 50% longer. So, if encoding a clip in Huffyuv takes 1 unit of time, then a quick estimate would be:

1 Huffyuv
2 Fastest PNG
4 Normal PNG
16 Best PNG
24 Best w/ Auto-Delta.Those numbers will get a little more refined with some more testing.

Here (http://insipid.us:81/png-task.png) is an image that shows decoding the Simpsons Clip. The first hump is Huffyuv and the second hump is "All I frames Normal". There is no decoding difference with video encoded with Fastest, Normal, or Best. The 2 P frames stayed mostly at 94-98% CPU and hits 100% every now and then. For 100 P frames, it stayed at 100% the whole time. For the Auto-Delta, the CPU usage was about halfway inbetween 2 and 100 P frames.

[Koepi]

Hm, nice results - so it's definatly useful for anime/cartoon intermediate files.

My credits go out to jcsston - sorry for any confusion :) (Still thakns for the tests and announcement/forcing jcsston to code that ;) )

Best regards
Koepi

[Tommy Carrot]

Why are you compare it to Huffyuv? There are much better lossless codecs. I'm particularly curious how is it doing against ffv1 on animes or cartoons (i cannot test since i haven't got any right now).

EDIT: BTW, nice work! ;)

[Atamido]

Originally posted by Tommy Carrot
Why are you compare it to Huffyuv? There are much better lossless codecs. I'm particularly curious how is it doing against ffv1 on animes or cartoons I used Huffyuv because its the most common lossless codec. Almost everyone has used it, so its easier to get an idea.

I also wanted to try VBLE, but I'm not sure where to get it.

I made some tests with FFV1, but I couldn't play any of them back so I'm not sure about the numbers it produced. Although it did much better on the StarWars clip and a bit worse than Normal I frames on the Simpsons clip. If anyone can get this codec to work, please post a comparison.

[jcsston]

I havn't tested againist VBLE because VBLE only works in YV12 mode. And comparing a RGB24 codec againist a YUV codec isn't much of a comparsion. ;)

[Wilbert]

@Pamel,

The vble codec can be found here:

http://forum.doom9.org/showthread.php?s=&threadid=53305

[jcsston]

I say again, this codec in it's current state CANNOT be compared equally to VBLE or FFV1. Both those codecs work in YV12 colorspace, half the bits of RGB24. And neither support Alpha channel.

I don't see many people comparing 44.1Khz Monkey audio to 22.05Khz FLAC :p

[Human_USB]

On fast mode I get 4 FPS and on Best I get 0 to 1 FPS. Also I do not have Auto-Delta on. I wish I got the speed Pamel got.


*EDIT*
Also my video is upside down.

*EDIT 2*
I find that when I encode in Fast mode my video comes out upside down.

[Tommy Carrot]

Originally posted by jcsston
I say again, this codec in it's current state CANNOT be compared equally to VBLE or FFV1. Both those codecs work in YV12 colorspace, half the bits of RGB24. And neither support Alpha channel.

I don't see many people comparing 44.1Khz Monkey audio to 22.05Khz FLAC :p

Well, Loco (http://forum.doom9.org/showthread.php?s=&threadid=53305&highlight=loco) codec does support rgb colorspace, and there is an option to alpha channel support too, but i've never tried it, so i don't know if it really works.

BTW, the delta-frames are great idea! I've tried CorePNG on CGI, and the size gain is huge with delta-frames.

[jcsston]

Originally posted by Tommy Carrot
Well, Loco (http://forum.doom9.org/showthread.php?s=&threadid=53305&highlight=loco) codec does support rgb colorspace, and there is an option to alpha channel support too, but i've never tried it, so i don't know if it really works.
I tried out the Loco codec and on my test clip it was larger than the Huffyuv version (both in RGB24 mode). :confused:

[Atamido]

Originally posted by Human_USB
On fast mode I get 4 FPS and on Best I get 0 to 1 FPS. Also I do not have Auto-Delta on. I wish I got the speed Pamel got.

*EDIT*
Also my video is upside down. With a lower speed processor, you are probably much more able to give an idea of the speed difference between Huffyuv and CorePNG on a given clip because the processor will be the main bottleneck.

The upsidedown video is an issue with DirectShow using the VFW codec to decode. You should not see this if playing the file back in VirtualDub. This will be fixed very soon.

[Dead2]

Hmm... You say you support Alpha channel..?

Does that mean you use RGBA all the time, or is there an option to do just RGB? I guess alpha-disabled clips would benefit from that. Btw, are there any video clips with alpha yet? if so, what for?

Yuv support should/could be quite simple actually..
If I remember correctly, you could just add the 3 output yuv bitmaps together, then compress them using regular 256color png.. After all, that is what png is really good at.


_________________
| | u |
| y |_____|
| | v |
|_________|_____|


Another thing.. for .png images there is a util called "pngcrush" that basicly re-tightens the image for those 2-15% extra compression still without loosing anything.
This could be an option "Super-compression" or something. Unfortunately it tends to take time, but I would definetely use that for testclips that I have stored permanently in lossless format.

Also, if you look at the pngcrush site, there are mentions of a few tweaks they had to do to the zlib before it would be optimal. Maybe worth checking out aswell?

Good luck! We'll be watching your progress =)

-=Dead2=-

[jcsston]

Originally posted by Dead2
Hmm... You say you support Alpha channel..?

Does that mean you use RGBA all the time, or is there an option to do just RGB? I guess alpha-disabled clips would benefit from that. Btw, are there any video clips with alpha yet? if so, what for?

Yuv support should/could be quite simple actually..
If I remember correctly, you could just add the 3 output yuv bitmaps together, then compress them using regular 256color png.. After all, that is what png is really good at.


_________________
| | u |
| y |_____|
| | v |
|_________|_____|


Another thing.. for .png images there is a util called "pngcrush" that basicly re-tightens the image for those 2-15% extra compression still without loosing anything.
This could be an option "Super-compression" or something. Unfortunately it tends to take time, but I would definetely use that for testclips that I have stored permanently in lossless format.

Also, if you look at the pngcrush site, there are mentions of a few tweaks they had to do to the zlib before it would be optimal. Maybe worth checking out aswell?

Good luck! We'll be watching your progress =)

-=Dead2=-
The Alpha channel is only compressed/used if the input is RGB32. VirtualDub only copmressed to/from RGB24 so you don't have to worry about that. The most often clips to use the Alpha channel would likely be CGI or title clips that are being used to create videos.

Thanks for the idea of having different images for YUV.

I've looked into the various things pngcrush does, but most of the things that it does to improve compression are hard-coded (need a different compile for regular compression) and it also increases decode time.

I've fixed the image flip bug with 32-bit decoding. :)
Download CorePNG VFW Codec v0.6 (http://corecodec.org/download.php/74/CorePNG_vfw_v0.6.zip)

[BetaBoy]

I asked jcsston to create a MAIN project page for CorePNG on www.CoreCodec.org for easier access and because it needed it ;)
Get it here: http://corecodec.org/projects/corepng

FYI: for those looking for a nightly Source Code 'cron job' for all the CoreCodec.org projects (including Matroska and it's associated projects) go here: http://cvs.corecodec.org/nightly/

----
Dan "BetaBoy" Marlin

[MfA]

It would be nice to have some idea of the comparitive performance against FFV1, how about using avisynth to produce an avi with just a single color component to do the comparison for now?

[Human_USB]

Originally posted by Pamel
With a lower speed processor, you are probably much more able to give an idea of the speed difference between Huffyuv and CorePNG on a given clip because the processor will be the main bottleneck.

The upsidedown video is an issue with DirectShow using the VFW codec to decode. You should not see this if playing the file back in VirtualDub. This will be fixed very soon.



But the sad thing is I have a 1800+ XP with 256 of 2600 DDR. Also my Hard drive has 8 MBs of cache so I have no clue what is killing my speed.

[BetaBoy]

Jory just released v0.6 which fixes the flipped image bug.

http://corecodec.org/projects/corepng

[Chainmax]

I second the YUV request. Also (like I asked in the original thread), could B-Frames be implemented too? What about an optional lossy mode for P-Frames (and B-Frames if they get implemented)?

[Human_USB]

Ok.... that fixed the problem. I tryed encoding a Anime episode which is 23 minutes and VDM said it was going to be 6 GB when done!!! That is HUGE!

[Atamido]

Originally posted by Human_USB
I tryed encoding a Anime episode which is 23 minutes and VDM said it was going to be 6 GB when done!!! That is HUGE! Welcome to the world of lossless encoding. Make sure to use the Auto-Delta frames. What would the size of the file be for Huffyuv?

[Human_USB]

With Huffyuv I get about 6.3 GBs.... and I was using Auto-Delta in Fast mode. I know Lossless is larger because I use FLAC for all my music. But still 6 GB lossless when the VOBs are only 1.15 GBs is a little over kill in my eyes.

[Atamido]

Originally posted by Chainmax
I second the YUV request.I don't know how feasible that would be since the PNG only accepts RGB/A, and any attempt to combine frames would be pretty hackish.Also (like I asked in the original thread), could B-Frames be implemented too?In VFW you would have the B-Frame decoder lag. You could do it in DShow, but it would mean a lot more work. Say you have three frames ABC. When you go to compress B, you would have to compress it normally, take the diff of A/B and compress that, and then take the diff of B/C and compress that. The smallest one would get stored.What about an optional lossy mode for P-Frames (and B-Frames if they get implemented)? PNG doesn't have a "lossy" mode. But I did suggest to jcsston to have an option to convert to an 8bit(256 color) PNG. You could convert every P frame to 8bit before compressing and you would get a really high compression ratio, but I'm not sure how much affect that would have on image quality.

[Atamido]

Originally posted by Human_USB
With Huffyuv I get about 6.3 GBs.... and I was using Auto-Delta in Fast mode. I know Lossless is larger because I use FLAC for all my music. But still 6 GB lossless when the VOBs are only 1.15 GBs is a little over kill in my eyes. You have to remember that the VOBS are lossy compressed. It would be like converting a 128kbit MP3 to FLAC. You are going to put on a lot of size.

Huffyuv and CorePNG aren't meant to store your movies with. You use these when you would otherwise use uncompressed video, but you don't want it to take as much space. Here are a few examples of where they are useful:

1. You render movie clips with 3D Studio Max or Maya and you want to store them losslessly so that you can do stuff with them later without losing any quality.

2. You have an movie clip of something that you use in making some home movies. You can add these clip in knowing that they are the original quality. You could have a clip of fire with (up to 256) layers of transparency that you put on different parts of the film to make it look like there are fires. (You would need something like Premiere)

3. You want to edit a movie clip in several stages, but you don't want to lose any quality by compressing it at each stage.

If you have a lossy source that you just want to store, there isn't any reason to convert it to a lossless format as it would take much more space.

[Human_USB]

ok.... thanks.

[Tommy Carrot]

Optional lossy mode is totally pointless. You would still get a _huge_ file as a result. If loss is tolerable, xvid with quant 2 is still perfect, with much, much smaller filesize.

YUV (or YV12) support is essential imo. Most source is already YUV, so there would not be loss anyway, and the bitrate would be cutted to half, or even more (afaik yuv is usually more compressable than rgb).

Of course, it is a problem that it wouldn't be real MPNG anymore. :)

[TEB]

This is awsome. Is matroska as a container format supported?

teb

[jcsston]

Originally posted by TEB
This is awsome. Is matroska as a container format supported?

teb
Yes, this codec uses the standard VFW/DShow interface and can be used in just about any container.

[TEB]

is this codec any kind of smp optimized? or is the bottleneck elsewere?

[Human_USB]

BTW.... why not use MNG? Would that not make your life easyer?

[jcsston]

Originally posted by Human_USB
BTW.... why not use MNG? Would that not make your life easyer?
Not really. MNG is much too complex to be used as a video codec. MNG is in fact closer to Flash A few quotes from the MNG website (http://www.libpng.org/pub/mng/)
# object or sprite-based approach to animation, with commands to move, copy and paste images (rather than replicate them as in GIF)
# nested loops for complex animations

[Atamido]

Originally posted by TEB
is this codec any kind of smp optimized? or is the bottleneck elsewere? I don't think that the actual compression code from libpng is optimized at all for SMP, but there are improvements that could be made other places. For instance, when doing auto-delta frames, you could encode the normal frame and the delta at the same time using different threads instead of encoding them one after the other.

[Stabmaster-Arson]

Dual AMD MP 2600+ <=============

I hereby vote for SMP optimisation/support.

Cheers!

[Atamido]

Even though this is not fair because CorePNG currently only does RGB, I went ahead and used the original converted to YUY2(See below for FFV1) to test some other lossless codecs. I used the same Simpsons clip as before. (A DVD reencoded to DivX 3.11 so it uses a YV12 colorspace.101,288KB Huffyuv in YUY2
65,868KB Loco in YUY2
63,606KB VBLE in YUY2
47,422KB FFV1 in YV12*
40,603KB 1000 P frames Best with Auto-Delta frames in RGB*FFV1 will basicaly only work in the YV12 colorspace. So, if your input is YV12, then FFV1 is lossless. That means any filtering or other colorspaces are going to be losing data.

[Tommy Carrot]

The latest ffvfw has some problems, so i suggest to try this (http://athos.leffe.dnsalias.com/ffvfw-20030927.exe) version. I've made some test with this AVS script, which was made for highlighting the difference:

clip1=avisource("source.avi")
clip2=avisource("ffv1_ac.avi") #optionally use convertoyuy2
Subtract(clip1,clip2).Levels(127,1,129,0,255)


If the source is indeed in YV12 colorspace, there is no difference, so this codec is lossless.

EDIT: of course you have to set the colorspace of ffv1 to YV12 for this.

[Atamido]

Got it to work now. Had to set everything in the settings and AVISynth to YV12 and it showed lossless in the compare.

[Chainmax]

Questions:

Is png any good for natural 24bit stuff? I believe it isn't.

I also believe YV12 shoudln't be pursued for capturing.

[TheXung]

Of course YV12 should be pursued for capturing if the final compression format will be also in YV12. I mean what final compression format isn't in YV12, that's still in popular use?

It is biased to give comparison numbers but not show or describe the source. Was that a cartoon or natural? and was it captured or DVD?

[scharfis_brain]

If capturing directly in YV12 be sure to use interlaced YV12!
If not, you'll mess up the colors in interlaced video.

btw. capturing in YV12 makes vertical chromashifting difficult (VHS caps), because interlaced YV12 can only be shifted in steps of 4 lines vertical without loss, while YUV can be shifted lossles in steps of 2 lines...

scharfi, who always caps with YUV..

[Atamido]

Originally posted by Chainmax
Is png any good for natural 24bit stuff? I believe it isn't.Yes. The only difference between 24 bit RGB and 32 bit RGB is an extra 8 bits that can be used as an alpha channel. PNG is functions just fine without and alpha channel.

[Atamido]

Originally posted by TheXung
Of course YV12 should be pursued for capturing if the final compression format will be also in YV12. I mean what final compression format isn't in YV12, that's still in popular use?

It is biased to give comparison numbers but not show or describe the source. Was that a cartoon or natural? and was it captured or DVD? ] If you are planning on filtering the video at all after capture, then you would want RGB because you would have a more video data to use in the filters. If you are capturing and encoding strait to a YV12 format, then capturing in YV12 is the only thing that makes sense.

Sorry about those numbers. They were using the same Simpsons clip as before. You will notice I just copied and pasted the line for CorePNG.

[Mr_Khyron]

Originally posted by Pamel
If you are planning on filtering the video at all after capture, then you would want RGB because you would have a more video data to use in the filters. If you are capturing and encoding strait to a YV12 format, then capturing in YV12 is the only thing that makes sense.

there are many good YV12 filter from neuron2, sh0dan etc... :rolleyes:

[Atamido]

Originally posted by Mr_Khyron
there are many good YV12 filter from neuron2, sh0dan etc... :rolleyes: Whats your point? I said, "its better to filter with more data." I didn't say "you can't filter with YV12."

[Koepi]

I think what Mr_Khyron means is that you don't gain anything by converting from YUV to RGB. If you have sources in real RGB (i.e. TV cards internally do YUV due to the composite nature of the tv signal) you're right Pamel.
If you have a dvd or captured source you're most likely dealing with YUV, which you can upsample and convert to RGB of course - but this interpolation necessary doesn't give you "real" data to work on. From my experience this interpolation step makes colours "dirty".

Hm. I think at least this is what this is all about ;)

Regards
Koepi

[jcsston]

Originally posted by scharfis_brain
If capturing directly in YV12 be sure to use interlaced YV12!
If not, you'll mess up the colors in interlaced video.

btw. capturing in YV12 makes vertical chromashifting difficult (VHS caps), because interlaced YV12 can only be shifted in steps of 4 lines vertical without loss, while YUV can be shifted lossles in steps of 2 lines...

scharfi, who always caps with YUV..
Can you give me some infomation on interlaced YV12? I've read a number of AviSynth threads about it and it seems that VFW doesn't provide a way to tell the difference between interlaced YV12 and progressive YV12?

[scharfis_brain]

hmm. interlaced YV12 isn't easy to explain, but I'll try

a interlaced full frame holds two individual fields.
we can separate this frame into its two fields.
and now we apply a RGB to YV12 conversion fieldwise (to supress chroma mixing between the fields). this means, that a 768x288 large field will have a chroma resolution of 384x144. by weaving both fields togehter you'll get the full frame, but color information is also interlaced (at half res)

as you can see the chroma is really messed up.

I've upped two examples here: http://home.arcor.de/scharfis_brain/samples/

[kastro68]

i just gave it a try a few hours ago.

Unfortunately my cpu isn't fast enough to allow capture in Real Time.

I enabled the following options:
-delta frames
-auto-delta frames
-compression level 1
-All filters

[Chainmax]

Clarification: those two questions I made are from someone that isn't a Doom9 member. I just offered him to ask his questions here.

kastro68, what are your system specs?

[Atamido]

Originally posted by Koepi
I think what Mr_Khyron means is that you don't gain anything by converting from YUV to RGB. If you have sources in real RGB (i.e. TV cards internally do YUV due to the composite nature of the tv signal) you're right Pamel.
If you have a dvd or captured source you're most likely dealing with YUV, which you can upsample and convert to RGB of course - but this interpolation necessary doesn't give you "real" data to work on. From my experience this interpolation step makes colours "dirty".
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.

[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.

[TheXung]

Originally posted by MfA
there are ... 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.

But the context based adaptive correction should provide that. Pixels in a gradient will be in the same context and the error correction should get better after each pixel of the gradient. Not only that, but if not a steep gradient, the static predictor should be also very close to the right value.


The combination of the static and context based adaptive predictor makes for a very robust predictor; it isn't easily fooled by something as simple as gradients. I will refrain from commenting about dithered areas.

[MfA]

It predicts them, but the entropy coding cannot go below a bit per pixel.

[TheXung]

Originally posted by MfA
It predicts them, but the entropy coding cannot go below a bit per pixel.

hmmmm. Good point

[TheXung]

OK, I know this is really beating a dead horse but heck that sounds like fun.

Take this image http://www.people.virginia.edu/~xn4f/grad.png

JLS/PNG
17k/27k

reduced to 256 colors
10k/22k

reduced to 16 colors
2k/4k

Files available at http://www.people.virginia.edu/~xn4f/

Don't know how PNG does it, but it seems lacking somewhere. I've really tried a lot of things to improve on LOCO-I; even for artificial images, it's really hard to get any more.

[MfA]

Now do a 1D gradient :)

[TheXung]

Originally posted by MfA
Now do a 1D gradient :)

*shrug*
http://www.people.virginia.edu/~xn4f/grad4.png
14.0k/24.3k

http://www.people.virginia.edu/~xn4f/grad5.png
8.13k/9.29k

[MfA]

Mea culpa, seems I was wrong on that one ... I wonder what exactly the cause is then that png outperforms it so much on synthetic images such as this (ftp://links.uwaterloo.ca/pub/BragZone/GreySet2/France/france.gif).

Part of it may be the repetetive pattern, but even without it it beats it by a wide margin (especially with crush).

[TheXung]

Originally posted by MfA
Mea culpa, seems I was wrong on that one ... I wonder what exactly the cause is then that png outperforms it so much on synthetic images such as this (ftp://links.uwaterloo.ca/pub/BragZone/GreySet2/France/france.gif).

Part of it may be the repetetive pattern, but even without it it beats it by a wide margin (especially with crush).

Odd how PNG responds so well to this one. I haven't figured out what about this one that makes it so compressible for PNG. But I really don't see how PNGing JPEG-LS will benefit less than perfect gradients such as in cartoons.

[sh0dan]

There is one feature that I would LOVE to have implemented.

Reduced resolution!

When editing video speed is often more important than quality when doing the actual editing. I would very much like to be able to edit on a faster version of the video, and when the edit is finished replace the video with the full quality material.

The problem is that replacing the video with a higher resolution one often leads to problems. Therefore if the video codec was able to reduce the video size while compressing and dynamically upscale on decompression.

A bilinear downsize on compression and a nearest neighbor upscaling on decompression would be the best (or fastest at least).

Is this something that would make sense to CorePNG?

PS. I wouldn't mind optimizing the scalers.

[outlyer]

Originally posted by sh0dan
Is this something that would make sense to CorePNG?That would make the codec lossy (or did I misunderstood?) and so it wouldn't make much sense.

[jcsston]

Originally posted by sh0dan
There is one feature that I would LOVE to have implemented.

Reduced resolution!

When editing video speed is often more important than quality when doing the actual editing. I would very much like to be able to edit on a faster version of the video, and when the edit is finished replace the video with the full quality material.

The problem is that replacing the video with a higher resolution one often leads to problems. Therefore if the video codec was able to reduce the video size while compressing and dynamically upscale on decompression.

A bilinear downsize on compression and a nearest neighbor upscaling on decompression would be the best (or fastest at least).

Is this something that would make sense to CorePNG?

PS. I wouldn't mind optimizing the scalers.
That sounds interesting, but I think using nearest neighbor both ways would work better. Because repeated resizes with Bilnear can get ugly quickly but nearest neighbor shouldn't look any worse after many recompressions.

[sh0dan]

@outlyer: Why not?

@jcsston:
Yes, it would indeed be lossy, but the point is, that I would be able to replace the file with a loss-less file, when doing the final video without having to worry about videoprograms choking on it.

The main reason is speed - not the smaller filesize as such. Having 4x time processing speed (at half resolution), 10-16x at quater res would make initial editing in various programs much more fluid.

The reason for choosing bilinear is nicer quality. Multiple recompresses doesn't really apply, as it wouldn't make sense to recompress a bad-quality image IMO. Using nearest, for upscaling is purely a speed consideration.

I could see this as a useful addition to CorePNG, as the current speed makes it unusable for my editing needs - however, I wouldn't mind editing video at severely reduced quality, if only it was fast, and I was able to replace the file with a full-quality one later.

[ProfDrMorph]

why don't you just use a resize filter and create a file only for editing? You could use VDub to create that file ( with reduced resolution ), do your editing, then use the original file as source instead of the newly created file.

[outlyer]

Originally posted by sh0dan
@outlyer: Why not?

@jcsston:
Yes, it would indeed be lossy, but the point is, that I would be able to replace the file with a loss-less file, when doing the final video without having to worry about videoprograms choking on it.I understood you wanted to keep a downsampled version and upsample it on playback; a lossy process won't make sense in a codec focused in lossless processing.

Now, what I understand is that you want to use the downsampled version as a template for the edition of the original video... as ProfDrMorph points you can do this with the editing app AND this kind of process belongs to the editing app, IMHO (BTW maybe I still didn't understood it well :confused: ).

EDIT: Minor rewording.

[sh0dan]

I guess you don't use the same apps as I.

In After Effects, for instance many things are depending on the size of the input stream. It affects scaling, position, placement, etc. If I use a downsized version for editing, nothing I do would be the same if later replaced it with a better version.

Anyway - implemented it myself in HuffYUV. Works very nicely, even though it has to be made an option. ;)

[Chainmax]

I wanted to know if General Lee D Mented's suggestion was implemented and if there was any speed optimization ideas.
I also have a doubt, does CorePNG now supports RGB and YUV or just YUV?

[Atamido]

It supports RGB, YUY2, and YV12.

[Zarxrax]

@Shodan: You know in After Effects there is a feature that lets you replace your footage with lower quality versions, and this is what I normally use. Is there a reason why that isn't satisfactory for you?



Could someone explain the Drop Frame threshold option? When I set it to 1 it seems to just encode frames that are perfect duplicates of the previous as dropped frames. Is this correct? What happens when you set the threshold higher?

[Atamido]

Originally posted by Zarxrax
Could someone explain the Drop Frame threshold option? When I set it to 1 it seems to just encode frames that are perfect duplicates of the previous as dropped frames. Is this correct? What happens when you set the threshold higher? Thats correct. At 1, it will only drop one frame in a row if it is a perfect duplicate. So if you set it to 2, and you had 4 frames that were all identical, it would keep the first one, drop the next two as duplicates, and keep the fourth.

[Zarxrax]

Originally posted by Pamel
Thats correct. At 1, it will only drop one frame in a row if it is a perfect duplicate. So if you set it to 2, and you had 4 frames that were all identical, it would keep the first one, drop the next two as duplicates, and keep the fourth.

Hmm well that interesting, because when I set it to 1, it will keep encoding dropped frames until it hits one thats different. For example if i have a row of 100 frames that are the same, then the 101st frame is new, it will give me 2 real frames and 99 dropped frames.
When I set it to 10, I got NO output in my test clip. Every single frame comes out dropped.

[Atamido]

Oops, I got goofed up. I went and checked an old conversation on this and this is what was said about it:

<Pamel> What does the Drop frame do/base off of?
<jcsston> Set the Drop frames to 1 and it will drop frames that are exactly the same
<jcsston> ex. Set the size to 0
<Pamel> What about 2?
<jcsston> it will drop everything with a setting of 2
<Pamel> Is there a 1.5?
<jcsston> no

So, really that should be a on/off setting, but you just have to set it to 0 or 1.

[Zarxrax]

Ok, well I think I've found an issue with the frame dropping. It doesn't work when I encode in After Effects for some reason. I can then take the output file from after effects and run it through vdub and reencode it... and it creates the dropped frames this time... and encodes a hell of a lot faster due to this. Is this something with the way that After Effects hands frames to the encoder? Any way it could be fixed? It would mean about a 600% speedup for my After Effects encodes :D

[esby]

I got an issue with a segmented video using corePNG as codec.

And the problem is only showing while i'm loading it with
segmentedAvisource() in avs.

I don't know if it comes from:

- a bug in avs with segmentedavisource()
- a bug in corePNG vfw decoder, uncorrectly reporting the findsample information, that avs is not able to detect or correct, but vdub apparently corrects on the fly.
- God know what...

Well about the bug itself:
(i tested with 8.2 version)

If you use delta frames, with corePNG, and if you requests a frame (XX) via segmentedAviSource(), supposing (XX-5) is the first previous keyframe, the frame (XX) will be unproperly decoded.
Now if you requests XX-5, then (XX-4), ... (XX) will be properly decoded.

Of course, avs cache strategy comes into play too, and if you requested XX-5 first, each time you requests XX-5 again, and if it is still in the cache, you'll got the badly decoded frame.


I tried with Dsynth, modifying segmentedAvisource to enable directstreaming, the bug shows only in normal mode. (meaning in direct streaming it does not show up.)

I'm posting it here, since i tested with multi segmented div3 source,
and was not able to reproduce the bug here, So i suspect the second hypothesis.
Since sh0dan 'went' on this thread, i guess he can check on his side too.

esby

Edit:

Apparently the bug is showing even with avisource()
so I guess corePNG must be bugged somewhere.

[Jeroi]

Is does anyone have this codec latest source available? That old mirror does not work, neither corecodec.org.

[filler56789]

Is does anyone have this codec latest source available?

http://www.free-codecs.com/CorePNG_download.htm

NOTICE: the file "logo.png" in the RAR archive is corrupted.

[Jeroi]

In that package does not contain the source tho.

[filler56789]

I downloaded it, unpacked with Universal Extractor, and found a RAR file containing the MSVC source-code.

[zerowalker]

The source code is simply in the Installation itself.

Also, does the codec work for you guys, can you Encode something, cause i can't, just get errors.

EDIT:

Seems to relate to the codec not being able to handle 32 bit RGB, 24bit seems to work.

[jcsston]

I've uploaded an archive of the my old CorePNG project folder (source code),

https://dl.dropboxusercontent.com/u/217884/CorePNG.7z

It's been a long time since I touched the code, but everything should be there to compile it with Visual Studio C++.

Thanks,
Jory

[qyot27]

I've uploaded an archive of the my old CorePNG project folder (source code),

https://dl.dropboxusercontent.com/u/217884/CorePNG.7z

It's been a long time since I touched the code, but everything should be there to compile it with Visual Studio C++.

Thanks,
Jory
I've done a cvsimport from the tarball provided in the 7z archive. The result is on Github:
https://github.com/qyot27/CorePNG

But I'm not sure if it got everything that was supposed to have been there. The commits stop after December 2003, but many of the files in the 7z archive have modified dates in 2006-2008. I suppose that could be due to any post-2003 modifications not having been committed, but I don't know.