Colorspace descriptions #31

dericed · 2016-12-18T01:01:29Z

TO DO: remove redundancies with the ‘General Description’ section which
mostly focuses on colorspace

Comments welcome.

dericed · 2016-12-18T01:18:13Z

for reference: https://www.ietf.org/mail-archive/web/cellar/current/msg00070.html

JeromeMartinez · 2017-01-03T16:11:04Z

ffv1.md

@@ -198,22 +198,51 @@ $$Q_{i}[a-b]=Table_{i}[(a-b)\&255]$$

 ## Colorspace

+FFV1 supports two colorspaces: YCbCr and JPEG2000-RCT. In YCbCr, the Cb and Cr planes are optional, but MUST be used together if used. Omitting the Cb and Cr planes would code frames in grayscale without color data. For both YCbCr and JPEG2000-RCT, an optional Alpha plane can be used to code transparency data. In either colorspace, an FFV1 frame is composed of 1 to 4 planes that MUST use one of the following arragements:


the whole paragraph but the first sentence should be a bit below, after "### YCbCr"

dericed · 2017-01-07T17:17:45Z

I removed the redundancy between this new Colorspace section and the General Description (I may add to the General Description in a later PR). I also split lists of supported plane arrangements between YCbCr and JPEG2000-RCT as IIUC JPEG2000-RCT does not support Y or Y-alpha encoding though YCbCr does. Confirm?

Please re-review.

michaelni · 2017-01-07T21:02:13Z

Theres a trailing whitespace, what is "arragements", did you run a spell checker on this ?
Cb and Cr were defined first as Y depends on their value but they do not depend on the Y value. That way nothing refers to a future definition
The text mixes U/V and Cb/Cr

dericed · 2017-01-07T21:08:20Z

I dropped the RCT reordering.
"arragements" -> "arrangements"
U/V corrected to Cb/Cr

michaelni · 2017-01-07T22:41:09Z

The author name is dericed not Dave Rice

dericed · 2017-01-07T23:55:32Z

authorship updated, ready for review again

retokromer · 2017-01-08T10:39:28Z

ffv1.md

+- Y, Cb, Cr
+- Y, Cb, Cr, Alpha
+
+When FFV1 uses the YCbCr colorspace, the Y plane MUST be coded first. If the Cb and Cr planes are used then they MUST be coded after the Y plane. If an Alpha (transparency) plane is used, then it MUST be coded last.


I suggest to omit the (transparency), because for restoration purposes the Alpha channel can be used in other ways.

But is using alpha channel for non-transparency data a hack? If we remove transparency here, then we should also change the definition of alpha_plane as it references transparency.

Also other RFC's that reference alpha channels describe them as for transparency without acknowledgement of other purposes. See PNG: https://www.ietf.org/rfc/rfc2083.txt.

This is the way it has been defined and it’s actually used in (post-)production.

I was referring to film restoration, as we are looking at also from an archive’s point of view. Some scanners and restoration software use the alpha channel to match «problems» (e.g. scratches) and then to sweep them under the carpet – in order to avoid the user to see it, they increase a little the contrast, but that’s another topic. I don’t consider it a hack; it seems to me more like an alternate use.

I prefer without, but I’m happy with the majority’s point of view. What about something less absolute, like (e.g. transparency)? That would «allow» also other uses.

I prefer without, but I’m happy with the majority’s point of view. What about something less absolute, like (e.g. transparency)? That would «allow» also other uses.

https://en.wikipedia.org/wiki/Alpha_compositing
"alpha compositing is the process of combining an image with a background to create the appearance of partial or full transparency"

From my point of view, alpha is tied to transparency, and other use is an hack (e.g. I already saw some images using RGBA channels and saying "warning, it is CMYK, but as there was no metadata for CMYK we used RGBA metadata in the stream", or YCbCr metadata is used when it is XYZ...); from my point of view if the 4th channel is used for something else e.g. scratches, it should have its own metadata saying that this is not transparency.

To me also alpha seems tied to transparency. The PNG spec seems to presume this. If somehow alpha does not mean transparency in the context of FFV1, then if someone converts RGBA PNG to RGBA FFV1, should the FFV1 have a different meaning? ie in PNG alpha means transparency, but in FFV1 should alpha's use be unclear?

I prefer to leave as transparency. Possibly there is a need for other channels, such as infrared scanning, but that is not analogous to alpha and should be in another PR.

OK for keeping strictly transparency. I fully agree that the use made IRL is not a proper solution! An issue for this is open: #47

retokromer · 2017-01-08T10:43:20Z

ffv1.md

 ### JPEG2000-RCT

+JPEG2000-RCT is a Reversible Color Transform that codes RGB (red, green, blue) planes losslessly in a modified YCbCr colorspace. Reversible conversions between YCbCr and RGB use the following formulae.


I suggest to mention bijective or bijective function somewhere, because this is what the formulae are.

https://en.wikipedia.org/wiki/Bijection
"In mathematics, a bijection, bijective function or one-to-one correspondence is a function between the elements of two sets, where each element of one set is paired with exactly one element of the other set"

If I understand well, the formulae are not bijective because each element of YCbCr is not paired to something in RGB (there are some "illegal" values).
It is "reversible" as currently indicated in the spec (formulas permits to do RGB to YCbCr to RGB losslessly, but it does not permit to do YCbCr to RGB to YCbCr losslessly)

RGB -> YCbCr -> RGB losslessly, therefore RGB -> YCbCr -> RGB -> YCbCr -> RGB losslessly. Or do I miss something?

RGB -> YCbCr -> RGB -> YCbCr -> RGB losslessly

Right, because the "illegal" values are not used in this case.
But YCbCr -> RGB -> YCbCr is not (because some values in YCbCr will not be converted losslessly).
"bijective" requests that both sets have the same count of elements "one-to-one correspondence" (this is not the case here, you have 2x more elements in YCbCr set than in RGB set)
In specs:
In the equation below, the term "bits" represents bits_per_raw_sample+1 for RCT or bits_per_raw_sample otherwise", see the "n+1" for RCT, the sets have not the same size so no bijection can exist.

This is, if I understand well the RCT, the reason this is reversible (you can revert the transformation from RGB) and not bijective (you can not revert from YCbCr if you start from it, with all values).

I see, thank you! This must be the reason why many years ago we decided to work internally with big LUTs which are bijective (BTW working in Gray code instead of regular binary permits to reduce the rounding errors). Then I change my mind and do not suggest to mention bijective or bijective function.

The bijectivity of the RCT depends on the algebra it is used in. For example it is bijective in "Z,+,>>", it also is in "Z/nZ,+,>>" (the definition of >> does in fact not matter here as long as it is closed). In fact the RCT is bijective in a much wider range of cases, i think the set and + forming a quasigroup is sufficient. When the RCT is used as a mapping between sets of differing size it is of course not bijective.

Indeed. Thank very much you!

retokromer · 2017-01-08T10:47:15Z

ffv1.md

+In JPEG2000-RCT colorspace, the coding order would be left to right and then top to bottom, with values interleaved by lines and stored in this order:
+
+Y[1,1] Y[2,1] Cb[1,1] Cb[2,1] Cr[1,1] Cr[2,1] Y[1,2] Y[2,2] Cb[1,2] Cb[2,2] Cr[1,2] Cr[2,2]
+
 ## Coding of the sample difference

 Instead of coding the n+1 bits of the sample difference with Huffman-, or Range coding (or n+2 bits, in the case of RCT), only the n (or n+1) least significant bits are used, since this is sufficient to recover the original sample. In the equation below, the term "bits" represents bits_per_raw_sample+1 for RCT or bits_per_raw_sample otherwise:


Is the dash after Huffman- needed in English? Huffman or Range coding looks better to me.

dericed · 2017-01-08T14:00:23Z

I updated Huffman- to Huffman as @retokromer suggests.
I did not reference the JPEG2000-RCT as bijective since it isn't.
I did not remove reference to alpha for transparency as suggested. Other opinions here?

dericed · 2017-01-08T19:19:25Z

OK, in this case, ready for re-review/merge.

michaelni · 2017-01-08T20:37:45Z

This seems breaking xml build

ERROR: Unable to validate the XML document: draft-niedermayer-cellar-ffv1-01.xml
draft-niedermayer-cellar-ffv1-01.xml: Line 320: Element texttable content does not follow the DTD, expecting (preamble? , ttcol+ , c* , postamble?), got (c c c c)
draft-niedermayer-cellar-ffv1-01.xml: Line 321: Element t is not declared in c list of possible children
draft-niedermayer-cellar-ffv1-01.xml: Line 324: Element t is not declared in c list of possible children
draft-niedermayer-cellar-ffv1-01.xml: Line 328: Element t is not declared in c list of possible children
draft-niedermayer-cellar-ffv1-01.xml: Line 331: Element t is not declared in c list of possible children
make: *** [draft-niedermayer-cellar-ffv1-01.html] Error 1

michaelni · 2017-01-08T20:45:29Z

fixed

dericed · 2017-01-08T20:47:54Z

Thanks, I just force pushed the same idea.

JeromeMartinez reviewed Jan 3, 2017

View reviewed changes

dericed force-pushed the colorspace-descriptions branch from fe11f97 to 0eff938 Compare January 7, 2017 17:14

dericed changed the title ~~WIP Colorspace descriptions~~ Colorspace descriptions Jan 7, 2017

dericed force-pushed the colorspace-descriptions branch from 0eff938 to dd5ce95 Compare January 7, 2017 21:07

dericed force-pushed the colorspace-descriptions branch 3 times, most recently from b630414 to b585520 Compare January 7, 2017 23:54

retokromer reviewed Jan 8, 2017

View reviewed changes

extend colorspace descriptions

fed4fcb

dericed force-pushed the colorspace-descriptions branch from b585520 to fed4fcb Compare January 8, 2017 13:58

retokromer mentioned this pull request Jan 8, 2017

[v4] implementation of additional image data #47

Open

michaelni closed this in e69f975 Jan 8, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Colorspace descriptions #31

Colorspace descriptions #31

dericed commented Dec 18, 2016

dericed commented Dec 18, 2016

JeromeMartinez Jan 3, 2017

dericed commented Jan 7, 2017

michaelni commented Jan 7, 2017

dericed commented Jan 7, 2017

michaelni commented Jan 7, 2017

dericed commented Jan 7, 2017

retokromer Jan 8, 2017

dericed Jan 8, 2017

retokromer Jan 8, 2017

JeromeMartinez Jan 8, 2017

dericed Jan 8, 2017

retokromer Jan 8, 2017

retokromer Jan 8, 2017

JeromeMartinez Jan 8, 2017

retokromer Jan 8, 2017

JeromeMartinez Jan 8, 2017 •

edited

Loading

retokromer Jan 8, 2017 •

edited

Loading

michaelni Jan 8, 2017

retokromer Jan 8, 2017

retokromer Jan 8, 2017

dericed commented Jan 8, 2017

dericed commented Jan 8, 2017

michaelni commented Jan 8, 2017

michaelni commented Jan 8, 2017

dericed commented Jan 8, 2017

		@@ -198,22 +198,51 @@ $$Q_{i}[a-b]=Table_{i}[(a-b)\&255]$$

		## Colorspace

		FFV1 supports two colorspaces: YCbCr and JPEG2000-RCT. In YCbCr, the Cb and Cr planes are optional, but MUST be used together if used. Omitting the Cb and Cr planes would code frames in grayscale without color data. For both YCbCr and JPEG2000-RCT, an optional Alpha plane can be used to code transparency data. In either colorspace, an FFV1 frame is composed of 1 to 4 planes that MUST use one of the following arragements:

		### JPEG2000-RCT

		JPEG2000-RCT is a Reversible Color Transform that codes RGB (red, green, blue) planes losslessly in a modified YCbCr colorspace. Reversible conversions between YCbCr and RGB use the following formulae.

Colorspace descriptions #31

Colorspace descriptions #31

Conversation

dericed commented Dec 18, 2016

dericed commented Dec 18, 2016

Choose a reason for hiding this comment

dericed commented Jan 7, 2017

michaelni commented Jan 7, 2017

dericed commented Jan 7, 2017

michaelni commented Jan 7, 2017

dericed commented Jan 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JeromeMartinez Jan 8, 2017 • edited Loading

Choose a reason for hiding this comment

retokromer Jan 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dericed commented Jan 8, 2017

dericed commented Jan 8, 2017

michaelni commented Jan 8, 2017

michaelni commented Jan 8, 2017

dericed commented Jan 8, 2017

JeromeMartinez Jan 8, 2017 •

edited

Loading

retokromer Jan 8, 2017 •

edited

Loading