Intel's IPP 14-bits

[unix_sansei]

from the wikipedia
http://en.wikipedia.org/wiki/H.264

Intel's IPP supports 14-bits.

has anyone any test results or comparisons?

[shark37]

<w_ipp-samples_p_6.0.0.127.zip\ipp-samples\audio-video-
codecs\codec\h264_enc\readme.htm>


Intel ® Integrated Performance Primitives
H.264 Encoder
.
.
Parameter file description
UMC::H264EncoderParams class has method ReadParamFile. Using it the parameters can be read from text file. The structure of parameter file is the next
# | Type | Range | Description
---------------------------------------------------------------------------------------------------------------------------------
1 | string | | Reserved
2 | string | | The name of source YUV file
3 | int | >= 1 | Number of frames to encode
4 | 3 int | 1; >= 1; >= 0 | 1; Number of frames in between I frames; IDR interval
5 | 2 int | >= 0; 0 | Number of B frames between I (or P) and next P; 0
6 | 3 int | 1 – 16; 1; >= 0 | Number of reference frames; 1; Number of slices (if it set to 0 then encoder
| | | will set this number automatically correspond to number of threads)
7 | 2 int | 77, 100; >= 0 | profile_idc; level_idc (set 0 for automatic selection)
8 | int | >= 1 | Width of source
9 | int | >= 1 | Height of source
10 | int | 0 - 8 | Frame Rate Code (0 – 30fps, 1 – 15fps, 2 – 24fps, 3 – 25fps, 4 – 30fps, 5 – 30fps,
| | | 6 – 50fps, 7 – 60fps, 8 – 60fps)
11 | 3 int | 0 – 1; 8 – 12; 8 – 12 | chroma_format_idc (0 - monochrom, 1 - 420); bit_depth_luma; bit_depth_chroma
12 | 5 int | 0 – 3; 8 – 12; 0 – 1; | aux_format_idc; bit_depth_aux; alpha_incr_flag;
| | 0 – 2^(bit_depth_aux + 9) -1 ; | alpha_opaque_value;
| | 0 – 2^(bit_depth_aux + 9 -1 | alpha_transparent_value
13 | 5 int | 0 – 2; 0 – 51; 0 – 51; 0 – 51; >= 1| Rate Control method (0 - quant_codes, 1 - CBR, 2 – VBR);
| | | start qp values for I, P, B slices for Rate Control method 0;
| | | bitrate (bits per second) for Rate Control method 1 and 2
14 | 4 int | >1 – 6; 0 – 2; >= 1; >= 1 | Motion Estimation method; subblock split (0 – none, 1 – 8x8, 2 – 4x4);
| | | ME search region width; ME search region height
15 | 3 int | 0; 0; 0 | Reserved
16 | 2 int | 0 – 1; 0 – 1 | direct type (0 - temporal 1 - spatial); direct_inference_flag
17 | 3 int | 0 – 2; -12 – 12; -12 – 12 | disable_deblocking_idc (1 – off, 0 – on, 2 – on without crossing slice boundaries);
| | | deblocking_filter_alpha; deblocking_filter_beta
18 | 3 int | 0 – 1; 0 – 1; 0 – 1 | transform_8x8_mode (0 – off, 1 – on); scaling matrices (0 - use standard,
| | | 1 - use default scaling matrices for 8x8 quantization);
| | | qpprime_y_zero_transform_bypass_flag
19 | int | >= 1 | Reserved (must be the same as Width of source)
20 | int | >= 1 | Reserved (must be the same as Height of source)
21 | 2 int | 0 – 1; 0 – 2 | entropy coding mode (0 – cavlc, 1 – cabac); cabac_init_idc
22 | int | 0 – 1 | picture coding type (0 - only FRM, 1 - only FLD )
23 | string | “0 sample.log” | Reserved


Known Limitations

Encoder produce only JM9.2 compatible streams
SI and SP slice types are not supported.
Slice Data Partitioning is not supported.
- Annex A - Enforcement of Profile and Level Restrictions is not supported.
- Annex C - Full conformance with HRD (Hypothetical Reference Decoder) is not supported.
- Annex D - SEI (Supplemental Enhancement Information) is not supported.
- Annex E - VUI (Video Usability Information) is not supported.
Long Term Reference frames are not supported.
FMO (flexible macroblock ordering) is not supported.
ASO (arbitrary slice order) is not supported.
Weighted prediction is not supported.
The encoder only supports slices with MBs in raster order. All slices are the same size (in MBs) with any remainder going to the final slice. The maximum number of slices is the number of MB rows (one slice per row of 16x16 MBs).
Encoder does not support frame resizing. Thus input and output frame sizes should be the same.
Custom and default scale matrices are not supported. Standard scaling matrices are always used.
Transform 8x8 can be used for inter coding only.
The encoder assumes that input VideoData object contains frame in YUV420 (I420 according to FOURCC.org) format.

[unix_sansei]

thanks.

i downloaded the Par Studio and IPP with the samples. so it appears it's 12-bit, still much better than any other encoder.

have you got the application with the samples to build and encoded anything @ 12-bit? i keep getting strange conflicts between different IPP lib versions.

[slavickas]

I hope you have 64 bit P4 processor, still much better than any other CPU

[unix_sansei]

I hope you have 64 bit P4 processor, still much better than any other CPU

post your encoded 12-bit file versus 8-bit if you have one. dyanmic range of the bit depth is crucial for quality.

easy to talk, let's see you deliver something.

[shark37]

have you got the application with the samples to build and encoded anything @ 12-bit? i keep getting strange conflicts between different IPP lib versions.

Just tried
.\ipp-samples\audio-video-codecs\build32.bat cl9

It executes perfectly well here with
w_ipp-samples_p_6.0.0.127.zip
Intel IPP 6.0.1.070

Concerning extended data range encodings -- sorry -- nothing to deliver ;-)

[nurbs]

post your encoded 12-bit file versus 8-bit if you have one. dyanmic range of the bit depth is crucial for quality.

easy to talk, let's see you deliver something.

Hard to deliver something when the average person has no access to 12-bit sources. Broadcast, blu-ray, etc. are all 8-bit. Also most of the people in the avisynth forum seem to agree that higher bitdepth is more important for preprocessing then for viewing, especially at higher resolutions where the problems that stem from yv12 subsampling are less noticable.

[unix_sansei]

Hard to deliver something when the average person has no access to 12-bit sources. Broadcast, blu-ray, etc. are all 8-bit. Also most of the people in the avisynth forum seem to agree that higher bitdepth is more important for preprocessing then for viewing, especially at higher resolutions where the problems that stem from yv12 subsampling are less noticable.

thanks, i'll head over and see what's up with the avs forum.

like you said most people have never seen a full 16-bit film, once you do, you see things differently.

my sources are full Y16 images and when i compare to lowly 8-bit, the images are drastically different. the extra byte drops the PSNR into the dust, the control over the gamma curve, you can have texture in the shadows and still have true black without being 'crushed', similarly with the whites.

examining Y8 or YUV, they seem very 'flat'.

most image processing routines so far are really lacking for big uncompressed 16-bit so i've done most of my processing in Matlab, at full res, direct matrix manipulation. even then most wavelet/denoise/filters routines get 'lost' in the background. you'll die of old age before the image gets processed.

[unix_sansei]

Just tried
.\ipp-samples\audio-video-codecs\build32.bat cl9

It executes perfectly well here with
w_ipp-samples_p_6.0.0.127.zip
Intel IPP 6.0.1.070

Concerning extended data range encodings -- sorry -- nothing to deliver ;-)

i finally got it to build with the latest Par Studio, but had to rework all of the Intel bat and makefiles files. there are some nasty conflicts with the openmp libs, libguide40, vcomb, and libiomp5md especially if you the MKL and fortran compiler installed.

if i want to do a test run what settings would you suggest for h264?

these guys did interesting comparisons

http://www.compression.ru/video/codec_comparison/mpeg-4_avc_h264_2007_en.html

here's what i've got so far. i'm not sure about the quant of VOP settings, i'm looking to establish a baseline for lossless Y16

!! MPEG-4 videoencoder sample !!
test1.y16 // name of source files
1920 // horizontal_size
1080 // vertical_size
300 // number of frames
30 // frame scale
1 // frame interval
0 // quant_type: 0 - H263, 1 - the first quantization method
12 // IVOP quant
12 // PVOP quant
12 // BVOP quant
0 // short_video_header
300 // max I-VOP distance
0 // num of successive B-VOPs
50 // P-VOP searchWidth in full pel
50 // P-VOP searchHeight in full pel
50 // B-VOP searchWidth Forw in full pel
50 // B-VOP searchHeight Forw in full pel
50 // B-VOP searchWidth Back in full pel
50 // B-VOP searchHeight Back in full pel
0 // Motion Estimation algorithm: 0-full, 1-fast
4 // Motion Estimation accuracy: 1-full, 2-half, 4-quarter
0 // 0 - 1MV 1 - 4MV
1 // obmc_disable
0 // Rounding Control enable
0 // calculate PSNR
0 // RateControl 0 - no, 1 - FrameLavel(VBR), 2 - MacroblockLevel (CBR)
950000 // BitRate, bps
70 // SceneChangeThreshold, %
0 // insert GOV before I-frames
0 // repeat VOL before I-frames
0 // insert GOB/VideoPackets
4096 // VideoPacket length, bit
0 // data_partitioned
0 // reversible_vlc
0 // interlaced
0 // top_field_first
0 // alternate_vertical_scan_flag
1 // ME pred - 0 - field; 1 - frame; 2 - field+frame
0 // sprites - 0 - none, 1 - basic, 2 - GMC
0 // no_of_sprite_warping_points
0 // sprite_warping_accuracy

/* CommentLine: H.264 Sequence.*/
test2.y16 /* name of source files */
300 /* number of frames to encode */
1 200 1 /* 1(reserved) , N (# of frames in between I frames), IDR interval. */
3 1 /* Number of B frames between I (or P) and next P, treat B as a reference (only 0 is supported!) */
4 1 0 /* num_ref_frames (2-16), minimum length of list1 for backward prediction (only 1 is supported!), number of slices. */
100 0 /* profile_idc (77-main, 100-high); level_idc (set 0 for automatic selection) (check that num_ref_frames and frame size are in accordance with the level) */
1920 /* horizontal_size */
1080 /* vertical_size */
2 /* frame_rate_code [0,8] (0-30 fps,1-15 fps,2-24 fps,3-25 fps,4-30 fps,5-30 fps,6-50 fps,7-60 fps,8-60 fps)*/
0 12 12 /* High profile: chroma_format_idc (0 - monochrom, 1 - 420, 2 - 422), bit_depth_luma [8,12], bit_depth_chroma [8,12] */
0 12 0 0 0 /* High profile: aux_format_idc: [0,3], bit_depth_aux: [8,12], alpha_incr_flag: 0, 1; alpha_opaque_value: [0, 2^(bit_depth_aux + 9) -1]; alpha_transparent_value: [0, 2^(bit_depth_aux + 9) - 1] */
2 0 0 0 9500000 /* RC method(0 - quant_codes, 1 - CBR MBwise, 2 - CBR framewise, 3 - Debug); start qp values for I, P, B slices; bitrate (bits per second) */
2 1 8 8 /* ME method (1-6), subblock split, search x,search_y */
0 0 0 /* weighted prediction, weighted biprediction implicit weighted biprediction (not supported!)*/
1 0 /* direct type (0 - temporal 1 - spatial 2 - auto); direct_inference_flag */
1 0 0 /* disable_deblocking_idc: 1-- off, 0 - on, 2 -- on(without crossing slice boundaries); deblocking_filter_alpha, deblocking_filter_beta */
0 0 0 /* High profile: transform_8x8_mode: 0 -- off, 1 - on; 0 -- use standard, 1 -- use default scaling matrices for 8x8 quantization; qpprime_y_zero_transform_bypass_flag: (0, 1) */
1920 /* display_horizontal_size */
1080 /* display_vertical_size */
1 2 /* entropy coding mode (0-cavlc,1-cabac); cabac_init_idc (0,1,2) */
0 /* picture coding type (0 - only FRM, 1 - only FLD , 2 - only AFRM, 3 - pure PicAFF(no MBAFF) 4 PicAFF + MBAFF). Only 0 (FRM) is supported! */
3 0 /* speed/quality grade [0,3] (0-maximum speed, 3-maximum quality); OptimalQuantization (0, 1) */

[benwaggoner]

like you said most people have never seen a full 16-bit film, once you do, you see things differently.

my sources are full Y16 images and when i compare to lowly 8-bit, the images are drastically different. the extra byte drops the PSNR into the dust, the control over the gamma curve, you can have texture in the shadows and still have true black without being 'crushed', similarly with the whites.

examining Y8 or YUV, they seem very 'flat'.
Well, it's really all about the dithering. Just truncating 16-bit to 8-bit can yield a lot of banding. But a well-tuned ditherer is pretty much perceptually transparent, particularly in HD. From a HVS perspective, we're looking for those sharp edges, and truncation gives us those in spades. But 8-bits is generally plenty with most content with dithering to eliminate the introduction of false edges. Kind of like 16-bit audio; 24-bit sounds better than bad 16-bit, but good 16-bit is pretty much identical.

[unix_sansei]

Well, it's really all about the dithering. Just truncating 16-bit to 8-bit can yield a lot of banding. But a well-tuned ditherer is pretty much perceptually transparent, particularly in HD. From a HVS perspective, we're looking for those sharp edges, and truncation gives us those in spades. But 8-bits is generally plenty with most content with dithering to eliminate the introduction of false edges. Kind of like 16-bit audio; 24-bit sounds better than bad 16-bit, but good 16-bit is pretty much identical.

i've been working a lot with IM libs for my film and i can see a definite difference between 8-bit linear, 10-bit log, and 16-bit blows them both away even on my non-professional monitor.

http://www.imagemagick.org/script/motion-picture.php

they are examples here.

all the audio we recorded at 32-bit/192khz with a microphone that had a flat response from 5 to 50khz. there are so many details people haven't heard, even professionals at a sound studio in Burbank were amazed. when i reduce it down with adobe audition to something DTS or AC3, even at the highest, best quality there is still a lot of information lost.

[Sharktooth]

i doubt you would spot the difference between a properly dithered 8bit image and 16 bit image, expecially on a non professional monitor.

[unix_sansei]

you can believe whatever you want. i'm not here to convince anyone.

i'm stating my subjective opinion when you display a native 4k x 6k @16bit image at 100%, unless you know of a monitor capable that resolution, it is very easy. you cannot look at high-res image downsampled to a 1k or 1.5k monitor so the image 'fits' the screen and expect to see final results. i have weekly conversations with professional film labs about the subject and quality control.

[Sharktooth]

are you kidding? you talk about 4k x 6k as if most monitors can support that res... most monitors cant even display more than "some thousands of colors"...
btw, as Ben said, expecially at those high resolutions, dithering can do miracles...

edit: now, if you tell me you can distinguish the difference between this (http://www.webalice.it/f.corriga/temp/8bit_palette.psd) and this (http://www.webalice.it/f.corriga/temp/48bit_RGB.psd) even on a FullHD monitor (without zooming), ill eat popcorns for the rest of my life...

note: the first image is 8bit palette (256 colors!) while the second is 48bit RGB...
note2: you'll need a program that supports 16bits per channel (48bit RGB) to display the second picture correctly.
note3: the 8bit palette sample was downsampled from the original 48bit sample.

[MfA]

i'm stating my subjective opinion when you display a native 4k x 6k @16bit image at 100%, unless you know of a monitor capable that resolution, it is very easy.
I don't know of any display or projector which can display at 16 bit per component except the dual modulation HDR displays (not talking about internal pre-processing here, but the amount of individual levels of intensity it can put on an actual screen).

[Manao]

Sharktooth : what are you trying to prove exactly ? A 8bit palette can still contain 256 48bits RGB colors.

[benwaggoner]

Sharktooth : what are you trying to prove exactly ? A 8bit palette can still contain 256 48bits RGB colors.
It's a good demonstration that dithering > number of discreet colors. Since we're visually looking for edges, as long as we're able to not introduce visually distracting aliasing, we don't really need any particular pixel to be super-precise.

Again, like audio. 16-bit can sound bad when badly filtered, but when done well, it'll sound pretty transparent compared to 24-bit or even 64-bit float.

There's been some research to suggest that 11-bit audio would be sufficient for normal hearing with normal content with good dithering.

[Sharktooth]

well, cant explain it better than how Ben did.

[Manao]

It's a good demonstration that dithering > number of discreet colors.It's not, the image is too simple and a 8bit palette is enough to make it perfect without dithering. It would be like comparing a 32bit audio whose samples are clamped between -128 and 127 with a 8bit palette audio. The 8 bit palette could still access losslessly all the values that the 32bit stream was using. Try the same thing on that picture (http://manao4.free.fr/g0000.png)

[Soulhunter]

Manao is right, the exampel with the 256 color palette makes no sense... >.>

But yes, dithering (http://soulhunter.razorbb.net/data/Dither.png) can make a big difference compared to no dithering (http://soulhunter.razorbb.net/data/NoDither.png), eh?

[Manao]

Soulhunter : your "dithered" picture isn't dithered

[Soulhunter]

Soulhunter : your "dithered" picture isn't dithered
Oh, you are right, I uploaded the wrong image!

Fixed it, sry... ^^;

[Sharktooth]

It's not, the image is too simple and a 8bit palette is enough to make it perfect without dithering. It would be like comparing a 32bit audio whose samples are clamped between -128 and 127 with a 8bit palette audio. The 8 bit palette could still access losslessly all the values that the 32bit stream was using. Try the same thing on that picture (http://manao4.free.fr/g0000.png)
in a picture you usually dont have all those colors, however, no problems...
here: http://www.webalice.it/f.corriga/temp/g0000_palette.png
obviously you can now spot some small differencies due to very smooth transients and the huge number of colors in the source image, but the converted sample it's still 256 colors!!! that's not even close to YV12 number of colors... and not even close to the difference depicted by the OT in his absurd examples...

[Manao]

the huge number of colors in the source image,There are "just" 30000 different colors in the source. The source was YV12, converted to RGB 24.

As for the rest, most LCD out there can only show 6bits per component, thus already do 8bits -> 6bits, so of course, you won't get anything by doing 16bits -> 6bits. If you are able to find a monitor that accept input > 8 bits (a SDI monitor for example), then you'll be able to spot the difference between 10 bits and 8 bits dithered - if a compression occurred. Because dithering doesn't encode well (doesn't encoded at all, I'd say).

As a stunning proof of that latest point, check out the file size of my png (34 KB) versus yours (2MB).

[Soulhunter]

True! Either you have to spend a ridicules amount of bitrate or you end up with banding... Something I learned from my debanding excursion back then... ;]

[Sharktooth]

There are "just" 30000 different colors in the source. The source was YV12, converted to RGB 24.

As for the rest, most LCD out there can only show 6bits per component, thus already do 8bits -> 6bits, so of course, you won't get anything by doing 16bits -> 6bits. If you are able to find a monitor that accept input > 8 bits (a SDI monitor for example), then you'll be able to spot the difference between 10 bits and 8 bits dithered - if a compression occurred. Because dithering doesn't encode well (doesn't encoded at all, I'd say).

As a stunning proof of that latest point, check out the file size of my png (34 KB) versus yours (2MB).
i mean, in a normal filmed picture it's hard to have all those colors.
as for the compression, well, you're right. that's why dithering should happen on DEcompression.

[unix_sansei]

are you kidding? you talk about 4k x 6k as if most monitors can support that res... most monitors cant even display more than "some thousands of colors"...
btw, as Ben said, expecially at those high resolutions, dithering can do miracles...

edit: now, if you tell me you can distinguish the difference between this (http://www.webalice.it/f.corriga/temp/8bit_palette.psd) and this (http://www.webalice.it/f.corriga/temp/48bit_RGB.psd) even on a FullHD monitor (without zooming), ill eat popcorns for the rest of my life...

note: the first image is 8bit palette (256 colors!) while the second is 48bit RGB...
note2: you'll need a program that supports 16bits per channel (48bit RGB) to display the second picture correctly.
note3: the 8bit palette sample was downsampled from the original 48bit sample.



no, you must be joking, there is no monitor on the planet that can display a full 4k x 6k image at 100% resolution at 4000dpi, an RGB image would be 143 Megabytes per frame, B&W 43 Megabytes per frame.

you would need a monitor the size of 3 feet by 6 feet.

do you have any idea of what 78 lp/mm means in terms of resolution? check out IMAX specs.

even imagemagick can process higher order bits for dpx files,
look here

http://imagemagick.org/script/motion-picture.php

i can easily tell the difference. on my screen with my images i can easily tell the difference, even though monitor is not $16,000 pro monitor, i have high end apps, that numerically process the data so that i can display the proper bit depth. for comparison i can define a range of values say 60000 to 65000 and compare that with 200 to 255 for 8 bit or 900 to 1000 for 10bit, and visually compare the image, the histograms, and gamma curves.

[Sharktooth]

i meant there are no monitors supporting those res...

however, you didnt answer my question. looking at the pics linked in my post, can you tell the difference (by visually comparing the pictures, without zooming and without analyzing them with any software... just using your eyes)?

[Phanton_13]

I can see the difference, but I have a trained eye for this things.

For experience I can tell that high bit depth only maters during mastering, but in the final product they are less important. The banding that the user see most of the time is due to cheap LCDs, and in the same monitor the same image with a adequate color transformation or dithering the banding is lost, but also is true that is possible to see a difference with pro equipment from a 8bit video and 10bit video but with proper mastering is impossible to see the difference in a 8bit monitor but wen that happens is due from bad mastering. Also is near impossible to see the difference in any situation between a 48bits RGB image and a 32bits logarithmic scaled image with this format (8 bit logarithmic intensity scale + 24bits RGB, this work similar to a float number) due to the eye limitations.

[Sharktooth]

that's a 256 colors palette image versus a 48 bit image.
i cant see any dynamic range difference, neither "dramatic" differencies.
and that pic is just 256 colors...
the real difference in higher depth pictures is in what you DONT see... and that info is only used for elaborating the image...

[unix_sansei]

i meant there are no monitors supporting those res...

however, you didnt answer my question. looking at the pics linked in my post, can you tell the difference (by visually comparing the pictures, without zooming and without analyzing them with any software... just using your eyes)?

hi, yes i looked at the dithering versus non-dithered, while these are good for technical benchmarking of how well an alogirthm is processing the LSB, i wouldn't say for mastering or quality control that is really that useful, just being honest. to me the test is looking at a HD images comparing say
RGB 16 to 12bit or 12-packed, 10bit or 10-packed, or a 10bit linear versus a 10-bit log. it's about the final image quality, the dithering is important part yes but i'm looking at final image.

i've got a link to high quality dpx

ftp://ftp.graphicsmagick.org/pub/dpx

download and display these images, you might need some high end viewer.

flowers-1920x1080-RGB-12.dpx

flowers-1920x1080-RGB-16.dpx

flowers-1920x1080-RGB-8.dpx

look at the shadows, especially under the flowers.

all of the shades of white in the clouds in the 16-bit version

[unix_sansei]

I can see the difference, but I have a trained eye for this things.

For experience I can tell that high bit depth only maters during mastering, but in the final product they are less important. The banding that the user see most of the time is due to cheap LCDs, and in the same monitor the same image with a adequate color transformation or dithering the banding is lost, but also is true that is possible to see a difference with pro equipment from a 8bit video and 10bit video but with proper mastering is impossible to see the difference in a 8bit monitor but wen that happens is due from bad mastering. Also is near impossible to see the difference in any situation between a 48bits RGB image and a 32bits logarithmic scaled image with this format (8 bit logarithmic intensity scale + 24bits RGB, this work similar to a float number) due to the eye limitations.

if i had unlimited money, sure, i'd just drop off about about 4TB to a post house and be finished.

have you seen the film 'Baraka'? this is the kind of quality i'm talking about. if you see the HD images of this film, they are simply stunning, the story of the film isn't much to speak of but spectacular images. how do you account for that? what did they do to achieve this with limitations on the eye response?

[Phanton_13]

how do you account for that? what did they do to achieve this with limitations on the eye response? I can't explain it because I didn't see it, but if you read this PHD thesis: http://www.fiu.edu/~ecast011/pdfs/%5BThesis%5D-%5BPh.D-2000%5D-Integration_of_Human_Color_Vision_Models_into_High_Quality_Image_Compression.pdf I think that you can learn something about the eyes limitations. Also I'm sure that a lot of that quality in Baraka can be explained by the postproduction and mastering process.

[MfA]

the dithering is important part yes but i'm looking at final image.
How exactly are you looking at that final image?

DVI-D is 8 bits per component, for me at least the quality of the dither is going to be the only distuingishing factor between those 3 images.

[unix_sansei]

Also I'm sure that a lot of that quality in Baraka can be explained by the postproduction and mastering process.

yes, that's the key, what the hell did they do in their dithering down to a mere 10-bit image to look so good. i'm going to ask my friend in Burbank and see what's he says.

[unix_sansei]

How exactly are you looking at that final image?

DVI-D is 8 bits per component, for me at least the quality of the dither is going to be the only distuingishing factor between those 3 images.

i don't know of any film image that dithers through every range of colors like the guy posted. thanks for posting those btw.

it's completely false, in the real world the boundary between images is not a slow degradation between UV and IR. it can jump from red to green or black to white to green, etc, etc. , in very few pixels.

i look at the image full scale, 100%, yes at 4k x 6k, they are off the screen and examine them piece by piece. i cal the monitor to a precise color space for the film. i'm looking for artifacts and for color corrections.

[benwaggoner]

I can't explain it because I didn't see it, but if you read this PHD thesis: http://www.fiu.edu/~ecast011/pdfs/%5BThesis%5D-%5BPh.D-2000%5D-Integration_of_Human_Color_Vision_Models_into_High_Quality_Image_Compression.pdf I think that you can learn something about the eyes limitations. Also I'm sure that a lot of that quality in Baraka can be explained by the postproduction and mastering process.
The cheapest way to get that HD "pop" is to shoot in bright sunlight. The more photons per 1/48th of a second, the better the SNR, be it film or digital acquisiton.

[unix_sansei]

The cheapest way to get that HD "pop" is to shoot in bright sunlight. The more photons per 1/48th of a second, the better the SNR, be it film or digital acquisiton.

Really has nothing to do with HD "pop", they have done something very unique and novel with their encoding technique.

[unix_sansei]

For anyone still interested.

I talked/emailed with people who worked on Baraka, those at Fotokem and Blink/Ascent media as well as the exec producer of Baraka. They used very high-end codecs as well as custom codecs and were absolutely balls to the wall stringent in their QC.

I'm going to meet with Blink/Ascent for a chat and benchmark.

Overall the general impression is that the Intel IPP is not ready for high QC or a production environment even with extra bits.

[Phanton_13]

That benchmark can be really interesting, also in the chat can be out some interesting things. I'm waiting for more info.