• 3 Posts
  • 115 Comments
Joined 28 days ago
cake
Cake day: September 2nd, 2025

help-circle









  • This wsa considered in the earlier days of the web, but then intentionally not enforced. HTML was specifically designed to not fall into the same scheme as most programming languages in that it should try to render what it could even if there was a lot going wrong (unlike most programming languages that try to fail fast).

    (And before someone comes after me for comparing HTML to programming languages, I am well aware that it is not Turing complete.)




  • To be honest, this just sounds like sugar shock. If your blood sugar rises too fast for insulin to be able to counteract it, then you start getting symptoms like drowsiness, fatigue, and “high-ness.” This can feel good, but it is basically doing damage to your brain, so I am not sure that this would be good long term. Then again, I suppose the same can be said for (hard) drugs.





  • I asked this same question on Reddit as well and figured I would copy over the answers that were given there so that Lemmy starts building up more searchable content/information.

    Reply from @bobbster574@reddit.com

    So the log data is just the way the luminance is stored in the image. It is the reason it is washed out; the image is being interpreted as a standard rec.709 SDR video when it isn’t. Log is often completely unlabelled leaving you to make sure youre using the correct operations for that specific log format.

    Ffmpeg shouldn’t affect the log gamma unless you apply a lut or perform tonemapping to transform the image. That said, I’m not sure if ffmpeg will pass through all your original metadata about shooting settings which may or may not affect the processing in your editing software.

    If you’re seeing significant colour shifts, something has potentially gone wrong but it’s also worth making sure that you check with your full processing pipeline rather than just a standard video player as it might be differences in interpretation between formats/metadata/etc rather than differences in pixel data.

    This is also worth doing to make sure that your downsampling and compression retain enough quality for your purposes.

    As the file is encoded in ProRes, it may actually be worth keeping the original resolution but compressing to high bitrate HEVC/H.265 which will generally not present any notable artefacts but still allow you to compress down to ¼-½ the size.

    Reply from @ThiccBruhMoment@reddit.com

    If they use av1, they should be able to hit ⅒ size and still have perfect quality. svtav1 preset 4 crf 20 should work.


  • Actually, sometimes having too many alarms can actually lead to alarm blindness where the person does not really recognize the alarms as important and just subconssciousely turns them into background noise.

    That being said, I still think at least in the short term this is a good idea. In the longer term, do you make sure that you are really well rested? I.e. the 15 minutes of boredom trick? (Do absolutely nothing for 15 minutes. You should get really bored. If you can manage to stay awake even through 15 minutes of boredom, then you are well rested, if not you need more sleep)


  • Thank you for the reply. I guess I didn’t make myself entirely clear in the original text, but I am talking about logarithmic color information, for better post production color grading. Not a text log.

    The actual video is actually a frontal shot of a person talking like you would see in a newsroom. There is no text present in the video.

    But yes, I absolutely agree with you, storing a text log as a video would be very inefficient and would require a huge amount of bitrate.