CorePNG - New LossLess codec

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