Answers.Body: <p>No, bit depth reduction always results in information loss, and even the chroma upscaling, while usually reversible with knowledge about the upscaling algorithm and the right algorithm to reverse it, is, without that special knowledge, technically not lossless either.</p>
  <p>However, for practical use cases, the perceptual loss in such a conversion can be virtually nonexistent, if dithering is used in the conversion step, as should always be done during bit depth reductions.</p>
  <p>But I'm not sure that you actually want lossless encoding, because except for H.265, none of the mentioned formats are able to encode losslessly, and H.265 is not particularly good at lossless encoding. So, be careful how you use that word. If you mean perceptually lossless, don't call it lossless.</p>
  <p>For lossy encoding, using the same format as the input format indeed provides advantages, although it's probably not that important here, considering that your camera encoder should have very different behaviour from a proper CPU encoder like the common x265.</p>
  <p>H.265 does not support 16 bit, the highest it supports is 12 bits. And every encoder has at least two important parameters that should always be set consciously by the user: effort/speed and quality/bitrate. In this case you want to set the effort/speed parameter &quot;preset&quot; (I highly recommend value &quot;slow&quot;), and the quality parameter &quot;crf&quot; (lower means higher quality). Always make sure to encode in a bit depth of at least 10 when doing lossy encoding, if possible, to prevent ugly banding artifacts.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-31T08:55:52.983Z
Answers.LastActivityDate: 2023-10-31T08:55:52.983Z
Answers.UserDisplayName: damian101
Answers.Body: <p>Shot answer: No, not really.
  While 16-bit does allow for a wider range compared to 10-bit, you won't be able to recover the information that has been lost when saving it in 10-bit initially.
  Therefore, converting to yub444p16 will involve some form of interpolation/upsampling.
  This could introduce some quality differences, but in my experience they are very subtle.
  You will have to try for yourself if they are acceptable though.</p>
  <p>You can use the following two commands to change the format:</p>
  <pre class="lang-bash prettyprint-override"><code>ffmpeg -i input.yuv -pix_fmt yuv444p output.yuv
  ffmpeg -i input.yuv -pix_fmt yuv444p16 output.yuv
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-09-30T06:53:51.840Z
Answers.LastActivityDate: 2023-09-30T06:53:51.840Z
Answers.UserDisplayName: Euklios
Body: <p>I have a 10-bit XAVC-HS file encoded with yuv422p10le pixel format and would like to render it out of my NLE, but my GPU does not support this. It does, however, support yuv444p and yuv444p16. Can I encode in either of those without losing information, since 16 bits should just straight up save more information?</p>
  <p>I need to reencode in a format that preserves everything because due to workflow we need to chain two different NLEs. This is out of my hands. However, since there are a lot of files, I would rather render for five hours on the GPU than for 50 hours on my CPU.</p>
  <p><strong>Additional Details in case they are useful</strong></p>
  <p>The input file is straight out of a Sony ILME-FX3 in XAVC-HS 4k 200M 4:2:2 mode, which to my understanding outputs 10-bit h.265 files. I am rendering on an NVIDIA card under GNU/Linux, which severely limits compatibility. The program with which I am exporting gives me the choice between &quot;h.265/HEVC&quot;, &quot;ProRes&quot;, and &quot;DNxHD&quot;. I figured that since I am already in h.265, the former would probably be the best choice for lossless conversion, but I may well be wrong there.</p>
  <p>The files are in slog, and LUTs and colour grading are done on the reencoded files, so I really do not want to lose colour information in this step.</p>
  <p>Edit: choosing the h.265 yuv444p16le rendering shrinks my test file from 2.3G to 1.5G, which makes me rather suspicious.</p>
  
Tags: <encoding>
Title: Can I reencode losslessly from yuv422p10 to yuv444? Or into a different format?
UserDisplayName: Betta George
ThreadText: # Can I reencode losslessly from yuv422p10 to yuv444? Or into a different format?
  
  (Asked by: username_0 on 2023-09-28)
  
  I have a 10-bit XAVC-HS file encoded with yuv422p10le pixel format and would like to render it out of my NLE, but my GPU does not support this. It does, however, support yuv444p and yuv444p16. Can I encode in either of those without losing information, since 16 bits should just straight up save more information?
  
  I need to reencode in a format that preserves everything because due to workflow we need to chain two different NLEs. This is out of my hands. However, since there are a lot of files, I would rather render for five hours on the GPU than for 50 hours on my CPU.
  
  **Additional Details in case they are useful**
  
  The input file is straight out of a Sony ILME-FX3 in XAVC-HS 4k 200M 4:2:2 mode, which to my understanding outputs 10-bit h.265 files. I am rendering on an NVIDIA card under GNU/Linux, which severely limits compatibility. The program with which I am exporting gives me the choice between "h.265/HEVC", "ProRes", and "DNxHD". I figured that since I am already in h.265, the former would probably be the best choice for lossless conversion, but I may well be wrong there.
  
  The files are in slog, and LUTs and colour grading are done on the reencoded files, so I really do not want to lose colour information in this step.
  
  Edit: choosing the h.265 yuv444p16le rendering shrinks my test file from 2.3G to 1.5G, which makes me rather suspicious.
  
  **Tags:** encoding
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2023-10-31. Score: 0 | Accepted answer
  
  No, bit depth reduction always results in information loss, and even the chroma upscaling, while usually reversible with knowledge about the upscaling algorithm and the right algorithm to reverse it, is, without that special knowledge, technically not lossless either.
  
  However, for practical use cases, the perceptual loss in such a conversion can be virtually nonexistent, if dithering is used in the conversion step, as should always be done during bit depth reductions.
  
  But I'm not sure that you actually want lossless encoding, because except for H.265, none of the mentioned formats are able to encode losslessly, and H.265 is not particularly good at lossless encoding. So, be careful how you use that word. If you mean perceptually lossless, don't call it lossless.
  
  For lossy encoding, using the same format as the input format indeed provides advantages, although it's probably not that important here, considering that your camera encoder should have very different behaviour from a proper CPU encoder like the common x265.
  
  H.265 does not support 16 bit, the highest it supports is 12 bits. And every encoder has at least two important parameters that should always be set consciously by the user: effort/speed and quality/bitrate. In this case you want to set the effort/speed parameter "preset" (I highly recommend value "slow"), and the quality parameter "crf" (lower means higher quality). Always make sure to encode in a bit depth of at least 10 when doing lossy encoding, if possible, to prevent ugly banding artifacts.
  
  
  ---
  
  ### Answer by username_2 on 2023-09-30. Score: 0
  
  Shot answer: No, not really.
  While 16-bit does allow for a wider range compared to 10-bit, you won't be able to recover the information that has been lost when saving it in 10-bit initially.
  Therefore, converting to yub444p16 will involve some form of interpolation/upsampling.
  This could introduce some quality differences, but in my experience they are very subtle.
  You will have to try for yourself if they are acceptable though.
  
  You can use the following two commands to change the format:
  
  ```bash
  ffmpeg -i input.yuv -pix_fmt yuv444p output.yuv
  ffmpeg -i input.yuv -pix_fmt yuv444p16 output.yuv
  
  ```
  
  
  ---
  
  