UCG1 Specification

[ardera]

UCG (Universal Compressed Graphics) is an image file format with the goal to achieve greater compression than paintutils files. Images stored in UCG can be up to 65535 pixels wide and 65535 pixels high, and can have up to 17colors per pixel (the 16 base colors and 1 transparent "color"). Images stored using the UCG file format are normally 10-40% of the size of the same image stored in paintutils format. To achieve this, the format uses a combination of Huffman Codes & Run-length Encoding. UCG is implemented in: https://github.com/ardera/libucg (for simple encoding & decoding) and: https://github.com/ardera/xaif (functionality of libucg + image manipulation and more userfriendly interface)

[viluon]

@ardera you might want to name this UCG3. However, why is this version 3? First off, that is not semantic versioning, secondly, this is the very first version of the standard.

[oeed]

To be honest, I actually kinda agree with @viluon. I'd use public version numbers. Using 3 might just confuse people. I'm certainly not using any old versions, there's no code that supports it in Silica either.

[ardera]

Okay @oeed, but you would have to delete all UCG files then; Working on this now

[oeed]

I'll just chuck them in a hex editor and change the 03 to 01 (that'll work, right?)

[oeed]

I think this is ready for a forums proposal release. As this is a brand new, non-meta standard it needs to receive feedback and approval from the CC community.

Essentially, make a topic in General with, at minimum, a direct link to this page and the most recent version of the proposal (i.e. this). You may also want to explain the format a bit. You don't need to got in to much detail if you don't want to (although it's obviously up to you), but giving a fairly brief outline as to the advantages of the format would be a good idea.

[oeed]

@demhydraz it's always been a requirement. The reason we haven't been doing it is none of the proposals yet have actually been new proposals. Says so in the original forums post "When they do that they will also need to create a topic in General with a link to the pull request so people are aware of the proposal."

[ardera]

@oeed Why shall I link this pull request discussion in the forum post?

[oeed]

@ardera the forums post needs a link to the pull request so people can interact with the discussion here and see changes. I was going to enforce having people commenting here and not the forums, but that just won't happen.

[oeed]

With @demhydraz's terminology #36 file, the 'byte' and 'word' definitions can be removed @ardera. I'd just link to the document and say they're big endian.

Otherwise I don't see any other issues that need to be fixed, We'll wait a few days and see if there are any other issues mentioned on the forums post and then till be merged.

[viluon]

Not ready to merge. I noticed quite a few weird sentences, I'm gonna fix them up and make a PR on ardera's fork

[ardera]

@viluon Yeah, sorry; English is not my mother language @oeed The byte section is necessary, it specifies how to read the bits of a byte. (Which bit is the first to process). (maybe it'd be good if @demhydraz also explained some bit-order and byte-order terms in the Terminology standard)

[viluon]

You should have waited for me @ardera, see #1. The changes I made are far more extensive.

[oeed]

You still have the thing explaining big endian, it's not needed.

[oeed]

You seem to have general approval and there haven't been any objections. So, well done @ardera, congratulations on being the first official 'new' proposal!

[viluon]

:tada: indeed @demhydraz! Congrats @ardera :clap: I think we are all looking to further collaboration with you!

[ardera]

Thank you! @viluon