Very clear and useful example. Thank you. I would like to insert it in chapter 7 of the latex manual as 7.5.4 Use case: x265. Obviously if you give me permission and Phyllis is fine with the insertion.
One question:
The lines color space … color primaries are used to provide the output file with an ICC profile (BT709)? Without these lines would you have no profile?
There is nothing against using the video profile and adapting it to your own needs, freely and without naming. I opened this fred to discuss export and compression issues. Obviously there is still a need for information, especially since video compression is not easy to understand. CGG can produce very high output quality, but you need to know which switches to set.
The color space information must be used explicitly so that it can be included in the video. CGG or FFmpeg does not write it by itself. Without this information the players (e.g. MPV) stick to the dimensions of the video and take the assumed color model from a table. With videos in the dimensions from 720 to 1080 this is like written bt709. For smaller dimensions, e.g. DVD, bt601 is assumed and for 4k and above it is bt2020. Normally this is not a problem, but if you want to export a FullHD without color loss to a smaller size like 576 for example, you have to inform the encoder as well as the decoder of the player. This also applies if the videos are to be loaded on video platforms, where they are then converted into videos of different sizes. It is a security measure to prevent false colors, such as the color profiles in digital photos and the copies made from them. But please do not confuse with the internal color space of CGG, that is (X11 s)RGB without color profile.
Great, you clarified a subject that made me confused.
Another question (if you can):
Settings → Preferences → appearance tab
What do the YUV Color space and YUV color range drop-down menus mean and how do they work?
I assume (!), these settings only affect the Format Settings, if the color model YUV-8 Bit was selected there. The YUV Color Range JPEG is slightly larger than MPEG. How much exactly did I forget, there is a description in WIKIPEDIA. The field of application of YUV is, as far as I know, SDTV and tube TV. The YUV color space regulates possibly the internal limitation of the color space with the internal processing. As written before, CGGs Composer works exclusively in (s)RGB. However, colour differences are still visible, YUV looks washed out in comparison to RGB. Maybe Phylis can say something?
I use the digital RGB[A-Float] model without exception to exclude color loss. Of course you can also use a smaller RGB-8 bit during editing, then it is a bit smoother because the amount of data is reduced. For the final export you must or should switch back to Float.
A supplement to CRF 16 because the manual was mentioned. A CRF of 16 delivers satisfactory results in most cases. However, if the film material is really grainy, a CRF 16 can lead to unwanted large files. In this case, a trial export of perhaps one minute should be performed. The resulting bit rate can be used to correct the CRF to 17,18,19… Remember, a CRF of 0 means lossless, the higher the number the stronger the compression. The approximate calculation of the final file size can be extrapolated from the sample export.
Thank you, Olaf. Your comments are very instructive. I enclose a .txt as an example of how I could add the new section to the manual. What do you think? Any corrections are welcome.
This is the kind of additional information that enhances the usefulness of the manual. From a technical viewpoint, it is beyond me, but for purposes of reviewing for the manual, I have the following commentary.
1 - Andrea, when you say add as section 7.5.5, does that mean that the original 7.5.5 will be renumbered (I just want to make sure it is not deleted because Piping Video… was a big deal to a specific user)?
2 - % The purpose of the comments in the profile is to allow users to
% description at the ready. – Should this be to have description at the ready. ?
3 - % grainy, see x265 Presets/Tunig – I think Tunig is supposed to be Tuning because Tunig is German for Tuning in english. ??
4 - video and take the assumed color model from a table. With videos in
the dimensions from 720 to 1080 this is like written bt709. – not sure what like written bt709 is supposed to be? Maybe like using bt709? or like writing bt709? I do not know technically.
Also, I agree with Olaf removing the credit of him for this from his changes. Originally I had only added specific credits when there was an overwhelming amount of work done or the information came directly from CV and I did not want the work of others to be unacknowledged. (P.S. I prefer to leave my name off since none of what I do is original work).
1- Sorry, Phyllis, I shouldve explained better. I assumed that Olaf only knew the current manual for which I used chapter 7, which in latex is 6 (because the current chapter 1 -Introduction- has not been numbered). In any case, when I insert section 6.5.5 in the manual_latex, all subsequent sections automatically scale without manual intervention. Piping video… will become 6.5.6 and so on. This is one of the many qualities of LaTeX.
2, 3 and 4- Ive corrected the text.
Credits: I dont agree with your name: in my opinion it should be put in the colophon, if not even in the title page. If not as an author at least as a co-author and curator.
Olaf, a further question: Instead of CRF vs VBR, wouldnt it become CRF vs Costant QP (CQP)?
I made the addition to the manual (pag 160-161), but since Im not loading it into my Git branch right now. You can only see the pdf I have in Dropbox at the following address:
(the last two chapters have not yet been revised) @Olaf
I tried to insert also the information that CinGG works on its internal color space, that is sRGB; it seems to me an essential information. You can see it on pag 74-75 of the pdf (Color model). But the color management of CinGG is not clear to me at all, so I ask you for a favor, if you want, to review it.
Good Guy should answer these technical questions from the developers point of view.
What I write here should be enough for home use, despite and because of the language barrier, and as generally understandable as possible.
CGG’s color spaces and color profiles have no priority https://cinelerra-gg.org/bugtracker/view.php?id=238
At this point the editor only needs to know that his monitor should be set to sRGB if color corrections are to be made with Cinelerra.
Yesterday I had revised the source code (except ABR) at the same time as your posting. These changes are not included, I see. A note on formatting, when removing comments, be careful to close the gaps, otherwise youll get a new paragraph after each sentence.
GG has already stated that it does not know color management. The hope is to find someone who knows how to do it.
I would say that there are two fixed points:
CinGG works internally in sRGB, so you have to set the monitor in sRGB.
If we use a video with YUV signal we have to set the project in YUV or transcode it as we want. Otherwise we will get darker images that distort the color correction (Mag). Using RGB-Float on a YUV signal should not lead to alterations, but I find them the same as if it were a simple 8-bit RGB.
@GG/Phyllis
Last thing: I found a blog that speaks in a simple and comprehensive way of transcoding between codecs (focus on DNxHR) whit FFmpeg:
I almost try to study and maybe pull out some presets for the Avid format. But I need to know if you can implement the .mxf container; Phyllis/GG is it proprietary?
Done, same link.
Im sorry, Im stupid enough to think you wanted separate paragraphs. So I left them even though I would have preferred a single paragraph
I think its best you write whatever comes to mind and wait for a bug report. Then the notifier is obliged to provide the conclusive and verifiable proof and you can use that for the manual. (^_^)/
