Is it possible to make my own test patterns? - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 
Thread Tools
post #1 of 14 Old 01-24-2019, 07:41 AM - Thread Starter
Member
 
nicolasb's Avatar
 
Join Date: May 2005
Location: London, England
Posts: 53
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 26
Is it possible to make my own test patterns?

I've been wondering if it's possible to make my own test pattern videos. It looks like it ought to be simple enough - make a bitmap or PNG image containing the desired pattern, then use one of any number of utilities for converting a picture to a video. But I'm having trouble finding a pic->vid application that won't mess up the image. First off, I specifically don't want it to map from full-range colour space to limited-range; so, for example, if my test image contains a rectangle that is red 16, green 16, black 16, I want that to be included in the video as 16,16,16 (or the YUV equivalent) - i.e. exactly video black-level. I don't want the conversion process to assume that it should be 16 steps above black and convert it to 32,32,32 (or thereabouts). I'd also like a little control over the compression and bit-rate, so as to make sure that it doesn't introduce compression artefacts.

For the moment I'm not considering how to make a 10-bit HDR test pattern - that, I know, will be much more complex. But if I can get an 8-bit rec.709 pattern working, that'll be a start.
nicolasb is offline  
Sponsored Links
Advertisement
 
post #2 of 14 Old 02-03-2019, 07:12 AM - Thread Starter
Member
 
nicolasb's Avatar
 
Join Date: May 2005
Location: London, England
Posts: 53
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 26
Okay, guess I'll bump this just once....

(bump)
nicolasb is offline  
post #3 of 14 Old 02-04-2019, 06:11 AM
M-V
Member
 
M-V's Avatar
 
Join Date: Feb 2017
Location: Saint-Petersburg, Russia
Posts: 109
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 70 Post(s)
Liked: 100
Quote:
Originally Posted by nicolasb View Post
It looks like it ought to be simple enough - make a bitmap or PNG image containing the desired pattern, then use one of any number of utilities for converting a picture to a video.
Try looking in direction of ffmpeg, it's very powerful tool.
For example, to create AVC (h264) video with static image
ffmpeg -i mypattern.png -vf format=yuv420p -c:v libx264 -preset medium mypattern.mp4

Quote:
Originally Posted by nicolasb View Post
For the moment I'm not considering how to make a 10-bit HDR test pattern - that, I know, will be much more complex.

It'll require 10bit hevc encoder (e.g. x265), HDR10 metadata additional options and there are some pitfalls with color conversion to Rec2020 but overwise it's no that different from SDR pattern.
M-V is offline  
Sponsored Links
Advertisement
 
post #4 of 14 Old 02-04-2019, 06:43 AM - Thread Starter
Member
 
nicolasb's Avatar
 
Join Date: May 2005
Location: London, England
Posts: 53
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 26
Quote:
Originally Posted by M-V View Post
ffmpeg -i mypattern.png -vf format=yuv420p -c:v libx264 -preset medium mypattern.mp4
That gives me a video that is just one frame long - in other words, a device plays back the entire video in 40 milliseconds.

How do I stretch that out to (say) 1 minute?
nicolasb is offline  
post #5 of 14 Old 02-04-2019, 09:37 AM
M-V
Member
 
M-V's Avatar
 
Join Date: Feb 2017
Location: Saint-Petersburg, Russia
Posts: 109
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 70 Post(s)
Liked: 100
@nicolasb
To repeat one image you can use -stream_loop
ffmpeg has tons of options and use cases. It's worth reading docs at https://ffmpeg.org/ffmpeg.html and search for examples, e.g. https://stackoverflow.com/questions/tagged/ffmpeg
M-V is offline  
post #6 of 14 Old 02-05-2019, 03:05 PM
AVS Forum Special Member
 
alluringreality's Avatar
 
Join Date: Jul 2006
Posts: 3,269
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 88 Post(s)
Liked: 90
The process used for AVS HD 709 was in line with your initial intentions. It looks like Rawsource has been replaced by RawSource26, otherwise I think the instructions linked below may still be mostly accurate.
https://www.avsforum.com/forum/139-d...l#post16837914
alluringreality is online now  
post #7 of 14 Old 02-09-2019, 12:48 PM
Advanced Member
 
jwhn's Avatar
 
Join Date: Dec 2013
Posts: 784
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 653 Post(s)
Liked: 163
I created my own patterns and used alluringreality's posts as a starting point. I ended up finding the original code and modified it so that I could create YUV files coded from scratch and then create any patterns / combinations I want.

I did this because I wanted to create a more automated process for using manual patterns with HCFR. Ted's patterns do a great job of this but I wanted to get customized timing for my set up and mimic all the HCFR measurement sequences. For example, I created a Full-Tilt Boogie automated sequence. I used a program called AutoIT to automate HCFR. Again, I took this idea from Ted but customized it.

I did my best to verify that the patterns are bit perfect, but I would appreciate if any experts could verify that I got it right.

@Anger.miki - I have been reading your thread on cheap test pattern generators. So it appears you have everything needed to verify test patterns. Would you mind taking a look at my patterns and let me know if they are accurate?

@ConnecTEDDD - I would value your feedback as well. Did I get these right?

And please note that I have purchased Ted and Ryan's disks and would highly recommend them even if you make your own patterns because there are so many great additional patterns that I would not even attempt to create that look at clipping and many other things.

The attached example is a color saturation sweep that matches the HCFR sweep.
Attached Files
File Type: zip ColorSat.zip (101.4 KB, 8 views)
jwhn is offline  
post #8 of 14 Old 02-14-2019, 05:42 AM
AVS Forum Special Member
 
ConnecTEDDD's Avatar
 
Join Date: Sep 2010
Location: Athens, Greece
Posts: 7,750
Mentioned: 178 Post(s)
Tagged: 1 Thread(s)
Quoted: 2919 Post(s)
Liked: 3549
Quote:
Originally Posted by jwhn View Post
@ConnecTEDDD - I would value your feedback as well. Did I get these right?
I did a quick check and its looking OK for random 3-4 patches I checked.

Ted's LightSpace CMS Calibration Disk Free Version for Free Calibration Software: LightSpace DPS / CalMAN ColorChecker / HCFR
S/W: LightSpace CMS, SpaceMan ICC, SpaceMatch DCM, CalMAN 5, CalMAN RGB, ChromaPure, ControlCAL
V/P: eeColor 3D LUT Box - P/G: DVDO AVLab TPG
Meters: JETI Specbos 1211, Klein K-10A, i1PRO2, i1PRO, SpectraCAL C6, i1D3, C5
ConnecTEDDD is offline  
post #9 of 14 Old 02-14-2019, 11:35 AM
Advanced Member
 
jwhn's Avatar
 
Join Date: Dec 2013
Posts: 784
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 653 Post(s)
Liked: 163
Quote:
Originally Posted by ConnecTEDDD View Post
I did a quick check and its looking OK for random 3-4 patches I checked.
Thank you for checking, Ted. I appreciate it. This exercise makes me realize how much effort must have gone into your pattern disk. ; )
jwhn is offline  
post #10 of 14 Old 02-14-2019, 12:56 PM
M-V
Member
 
M-V's Avatar
 
Join Date: Feb 2017
Location: Saint-Petersburg, Russia
Posts: 109
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 70 Post(s)
Liked: 100
Quote:
Originally Posted by jwhn View Post
I did my best to verify that the patterns are bit perfect, but I would appreciate if any experts could verify that I got it right.
I'm enthusiast like yourself but as far as I can see your patterns seem to be correct.

But speaking of bit perfect - technically it's not possible to make bit perfect video patterns because of the conversion RGB -> YCbCr
E.g., instead of RGB triplet 214,74,74 HCFR expects for 75% Red, after you encode and then decode video pattern you'll get something like RGB triplet 215,74,75
50% Cyan HCFR RGB 160,224,224 -> video pattern YCbCr -> RGB 159,224,225
50% Magenta HCFR RGB 178,121,178 -> video pattern YCbCr -> RGB 177,121,177
etc.
You can easily check that by taking screenshots from your video patterns and reading RGB code with color picker.


With 10 bits encoding and taking into account that software expects 8bit rounded values, errors should be considerably less.
So, I'm thinking that since we are in UHD era and all modern (~1-2 y.o.) players should capable of playing 10 bit SDR videos, it could be not such a bad idea to create 10 bit encoded calibration patterns for SDR.
M-V is offline  
post #11 of 14 Old 02-14-2019, 01:29 PM
Advanced Member
 
jwhn's Avatar
 
Join Date: Dec 2013
Posts: 784
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 653 Post(s)
Liked: 163
Quote:
Originally Posted by M-V View Post
I'm enthusiast like yourself but as far as I can see your patterns seem to be correct.

But speaking of bit perfect - technically it's not possible to make bit perfect video patterns because of the conversion RGB -> YCbCr
E.g., instead of RGB triplet 214,74,74 HCFR expects for 75% Red, after you encode and then decode video pattern you'll get something like RGB triplet 215,74,75
50% Cyan HCFR RGB 160,224,224 -> video pattern YCbCr -> RGB 159,224,225
50% Magenta HCFR RGB 178,121,178 -> video pattern YCbCr -> RGB 177,121,177
etc.
You can easily check that by taking screenshots from your video patterns and reading RGB code with color picker.


With 10 bits encoding and taking into account that software expects 8bit rounded values, errors should be considerably less.
So, I'm thinking that since we are in UHD era and all modern (~1-2 y.o.) players should capable of playing 10 bit SDR videos, it could be not such a bad idea to create 10 bit encoded calibration patterns for SDR.
Right, I learned about the errors due to the conversion. I believe this is one reason why the ASV709 patterns have rounding errors and why HCFR has the "use round down levels" option.

For this reason, I created raw YUV files and encoded straight to YCbCr. So I believe i avoided the conversion errors you are mentioning when I created the patterns. I know that these conversions can and will still happen at some point, but just wanted to clarify the approach I took.

And by the way, I use your HDR patterns also. Very nice job with those.
jwhn is offline  
post #12 of 14 Old 02-18-2019, 07:28 AM
M-V
Member
 
M-V's Avatar
 
Join Date: Feb 2017
Location: Saint-Petersburg, Russia
Posts: 109
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 70 Post(s)
Liked: 100
@jwhn
Thanks!


Conversion errors are different matter. With RGB->YCbCr conversion loss of color information is inevitable because it's in the math itself.
In other words, you can't convert RGB code (e.g. 160,224,224) to YCbCr and then convert it back and get the same RGB code, it'll differ (e.g. 159,224,225). In worst case scenario and with 8 bits calculations, difference will be up +-1 level in 2 out of 3 color channels (R,G,B).


I'll try to illustrate that point on practice with 8bit vs 10 bit encoded patterns when I'll get some free time.
M-V is offline  
post #13 of 14 Old 02-18-2019, 08:43 AM
Advanced Member
 
jwhn's Avatar
 
Join Date: Dec 2013
Posts: 784
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 653 Post(s)
Liked: 163
Quote:
Originally Posted by M-V View Post
@jwhn
Thanks!


Conversion errors are different matter. With RGB->YCbCr conversion loss of color information is inevitable because it's in the math itself.
In other words, you can't convert RGB code (e.g. 160,224,224) to YCbCr and then convert it back and get the same RGB code, it'll differ (e.g. 159,224,225). In worst case scenario and with 8 bits calculations, difference will be up +-1 level in 2 out of 3 color channels (R,G,B).


I'll try to illustrate that point on practice with 8bit vs 10 bit encoded patterns when I'll get some free time.
Understood. I'm aware and actually did a lot of tests converting back and forth across formats to test the results. Don't want you to spend you valuable free time on this! ; )

I should have said that I did the conversion at the beginning and rounded to nearest integer (vs. truncating) and then didn't convert back to RGB as I went straight from YUV to YCbCr. It seemed like this would better control the conversion errors compared to creating raw patterns in RGB format, say in Photoshop, and then converting to YCbCr. Maybe I'm wrong about that though.
jwhn is offline  
post #14 of 14 Old 06-10-2019, 02:22 AM
Newbie
 
hurodal's Avatar
 
Join Date: Jun 2019
Location: Barcelona
Posts: 5
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 0
Hi there,

Me too want to create my own patches.
I've created the original images in Photoshop and also created some clips but I fail to keep the original values in the final clip. Some clips (specially reds) do deviate a lot from the original values.

What I did was to create clips in Vegas Pro to then encode bith high bitrate but it's definitely not a good workflow. I was now thinking in creating a 'master' clip with some lossless codec within Premiere (I switched to it recently) to then encode in x264 with some encoder that I still don't know wich one to use (handbrake, MEGui...).

But after reading all these information seems to me that the process that alluringreality described in his thread seems more precise and also avoids the need of using a video editor.
With this process, I guess I should use the 0-255 in my images, right?

Any suggestion will be welcomed.

What surprises me the most is the step to conver to the image file YUV, I guess to minimize conversion errors, but... if there will be a conversion, why 'where' the conversion occurs matters?

Regards,

Regards,

Hugo
hurodal is offline  
Sponsored Links
Advertisement
 
Reply Display Calibration

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off