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.

[viluon]

This should include a version key-value pair as well, as stated by https://github.com/oeed/CraftOS-Standards/blob/master/Standard%20Proposal%20Guidelines.md

[ardera]

You're right. Does Version kv-pair mean the Specification or the standard?

[viluon]

I'd guess that is correct in your case.

[ardera]

Semantic versioning is not suitable for file formats. First, file formats are tested very thoroughly, so small patches are unwanted and don't really appear. Updates in general are unwanted for file formats. PNG has not been updated since 1999, although there are many better compression algorithms out there now than the one PNG uses; and the probable reason is backwards compatibility.

Also, when you use a two value version tag like MAJOR.MINOR, and you want to compare if yours is greater than another version, you would just do

if 256*major1 + minor1 > 256*major2 + minor2 then
  -- ...
end

To get the value of a word, you do 256*firstbyte + secondbyte. Notice the similarity? In practice, you would just read the version of a file as a word instead of a byte. I decided, I don't need this one byte more just to know if the decoder is able to read the file or not.

This is not the very first version of this file format. There were versions before that oeed and me used, and there were versions of libucg before that used these UCG versions. If I release libucg on the forums, I also release the older versions. Of course, noone's gonna use these, but I decided I don't fall back to version 1, because it'd miss the point of versioning.

[viluon]

Semantic versioning is the way to go. Nobody said you have to use it in your file format header.

(bump @demhydraz )

[viluon]

I wanted to see your approval of my statement @demhydraz.

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

🎉 indeed @demhydraz! Congrats @ardera 👏 I think we are all looking to further collaboration with you!

[ardera]

Thank you! @viluon