+antialias +dither

[IntMarine]

Hello

Is it possible to set antialias and dither to off during the convert process?

For example, I know when doing a convert to TIF files in GraphicsMagick I just add +antialias +dither to the command line and it turns them off. Single pixel white lines become single pixel white lines again instead of multiline greys, text stays pretty...

Thanks, C J

[Carsten]

What is the source resolution of the footage you are experiencing this with?

There once was an option for a high quality/low speed vs. lower quality/high speed scaling, but I guess there was rarely a need to make that decision.


- Carsten

[carl]

Is this with image files as input, or movie files? As Carsten asks, what is the source resolution?

[IntMarine]

Hi; 12-bit TIFFs are the answer to your question, though I've also tried with 4:4:4 QuickTime files which I remember having the same non-optimum effect.

I started this experiment while trying to create a series of 1 pixel white lines, each separated by a 1 pixel width of black, similar to parts of a lens MTF chart. Out of 20 lines, a couple of the lines will come out as single pixel white, but many would alias, that is, try to expand past the single pixel with 2 lines, one a whiter shade of grey and the other an even greyer grey. If I increased the separation by a few pixels, the lines will convert as white single pixel lines again.

===>>>I should point out here that I have only one 2K projector to test on, so it is not out of the question that my anomaly is generated there.

Anyway, this effect will happen with DOM when given a perfect 12-bit TIFF. But since my early originals were 8-bit tifs, I got to see a lot of variance as I learned to create a great 12 bit tif from SVG and PDF files using the 'convert' command.

When I put the lines one pixel apart and insert '+antialias' into the 'convert' instruction, they will come out crisp and white.

convert -density 144 WIP1a.svg -format TIFF -depth 12 +antialias +adjoin page-%d.tif (caution: this command generates a multi-hundred Meg file.)

I've just started testing '+dither', which I understand will have a similar effect on the antialiasing of fonts.

The bottom png is a fairly good representation of the attempt (with white lines 5 pixels apart and colored lines around the 5994 x 3240 original separated by 1 pixel), while the magnified circle shot shows the type of error that occurs. I'll try to take an actual photo of the screen tomorrow.

[carl]

Hi, so you're starting with 5994x3240 files and scaling them down in DCP-o-matic to 4K? Maybe I misunderstand, but I can't see how you'd avoid artefacts doing that... what are you expecting to happen with lines that sit across pixel boundaries after scaling?

[Carsten]

Hmm, it doesn't make sense to try this with test images that do not map 1:1 to the spec'd DCI containers.


DCI specs are based on a 1:1 pixel relation. While DOM scales differing resolutions to the standard DCI container measures, it is only to make things simpler for pre-existing footage conversions. The real idea is to feed a master into the DCP/J2k conversion with a 1:1 in/out pixel relation and only use cropping/letterboxing/pillarboxing if needed. There are actually expensive commercial DCP mastering solutions that do not allow to feed arbitrary resolutions into them, they simply expect you to conform the source footage to the few 2k and 4k container types. They will only touch the individual pixels for color/gamma adjustment.

Even with that 1:1 pixel relation, the J2k codec will create some compression artifacts/ringing around high contrast/color edges. So, there is always some 'smearing', even at the highest datarates/lowest compression settings.

Aside from that, a 2k projector/media block will not downscale a 4K DCP to 2k, but only extract the 2k wavelet compression level from the DCP. Technically, this is very different from downscaling.

Whatever - if you try to convert images with non 1:1 DCI container pixel relation and have no dithering or antialiasing, the outcome is clearly the worst imaginable - lost lines, doubled lines, severe aliasing, etc. Start to move these images around, and it will become very very nasty.

We probably could offer more help if you'd tell us what you are trying to achieve.

- Carsten

[IntMarine]

Carsten, thanks. Unfortunately, I choose a bad example. I have experienced this problem with every multiple including exact sizes...in fact, it was having problems with exact sizes that got me to try larger.

Right now I have to finish a project, but I'll get back to trying this again and have a more scientific methodology to show.

Again, thanks.

[cloud06]

If this is the case, it could be big problem for DOM.

Do you have any test images so we can try ourselves?

[Carsten]

I don't see a problem for DOM. Scaling always and fundamentally goes with some implications:

https://en.wikipedia.org/wiki/Image_scaling

A while ago I was evaluating various servers/media block's capabilities to play 'real' 4k content. Therefore, I created a series of test images, among them, a 4k checkerboard. I ran it through DCP-o-matic at various compression rates, displayed them on various DCI projectors, and also recreated uncompressed versions from the J2C generated. The only degradation was some minor ringing due to the J2K compression scheme.

Scaling is never perfekt, and for special applications, some images of special character may deserve different scaling algorithms.
I do my fair share of synthetical DCPs myself, and yes, for some of these weird tests I would prefer to have some special scaling options in DOM, but for all common uses, that is, real life content, bicubic as used by DOM 2.x should be sufficient.

If you choose 'no scaling' in DOM, or supply input resolutions that match the spec'd DCP container sizes, DOM will not apply any scaling.

- Carsten

4kchecker_j2c_crop.jpg

[Carsten]

A few days ago I did a test of a full container testchart, converted with DCP-o-matic, and played on our Barco. The captured screen image displayed as expected. As far as DCP-o-matic's scaling is concerned, it wouldn't be necessary to actually play the DCP through a projector to confirm it's behaviour, since it's easy to unwrap and check the J2C that DOM created directly.

Anyway - the DP2K-6E/ICMP combo used for the test is explicitly set to perform no scaling, and the result is as expected - neither DOM nor the projector applies any unintended or unexpected scaling/antialiasing for 1:1 input-output raster mapping.
Of course, DOM HAS to apply scaling/antialiasing for all other input/output raster relations (if pillar/letter boxing and/or cropping can't solve the bitmap adaption).

So, no reason to question DOM's capabilities here. The heavy antialiasing/filtering visible on those tiny chars is there in the source bitmap image already, as it has been created (rasterized) from a vector graphics set. One could choose to avoid this softening, but then the chars (and lines...) would show nasty break ups.

- Carsten

cyflynn_tiff_screenshot.png

cyflynn_DOMj2K_Barco_Photo_s.JPG