HELP! Sample RAW Bayer data needed...

[mrmuccy]

Wavelettes

Wavelettes

Dan,

Do you know anything about the wavelette compression that the RED is doing? I've some pixel mushing going on & wispers about the wavelettes.

Anybody know anything about their wavelette compression? Does it use lossless JPEG 2K like the DCI spec does??? Or did they create their own flavor?

I know, I know, it must be after the de-bayering...but you must be looking at these files to state "blockiness in the blacks" soooo...

 

[Graeme Nattress]

The compression is wavelet based, on the RAW data, not RGB Demosaiced data. It's 12bit, currently approx 10:1 or so. That's about all we say about REDCODE.

FYI, DCI spec is not lossless JPEG2000, but 9/7 JPEG2000 wavelet and lossy, XYZ, 12bit.

Graeme

 

[conrad gaunt]

Just out of curiosity, why would you want to go down this path?

My guess is he like options, and however good graeme de-mosaic is, and it looks great, there are others. Also I`d be interested in trying some ideas about superresolution I have, and that would involve a raw CFA. It could be a good way to get access to linear 12bit data too, because 10bit log is of no use to me when I get my Red. options?:usd:

edit: Are you using the Redcode wavelets to filter noise, and is this why we can only get are hands on 10bit log and not the 12bit linear the sensor produces?

 

[Graeme Nattress]

No, we don't use wavelet noise filters. And you can access the 16bit linear light data if you want in RedAlert.

Graeme

 

[Dan Hudgins]

Need DPX samples...

Need DPX samples...

Dan,

Do you know anything about the wavelette compression that the RED is doing? I've some pixel mushing going on & wispers about the wavelettes.

Anybody know anything about their wavelette compression? Does it use lossless JPEG 2K like the DCI spec does??? Or did they create their own flavor?

I know, I know, it must be after the de-bayering...but you must be looking at these files to state "blockiness in the blacks" soooo...

I am surprised that the images look as good as they do given this,

The compression is wavelet based, on the RAW data, not RGB Demosaiced data. It's 12bit, currently approx 10:1 or so. That's about all we say about REDCODE.

Gasp.:blink:

I wonder how they avoid hue shifts (btw hue and tint are different controls, athough because some TVs had both people got the names mixed up) from the artifacts, they would need to low pass filter the chroma one would think. I did see some odd hue modeling in early images, and thought that was why they had the saturation low. The OLPF helps reduce the sharpness of the boundry between red-green and green-blue pixels, but in saturated areas any phase delay would show up as a shift in the color.

I was told that the compression acts "...like mild noise reduction" or some words to that effect.

I was wondering how they were doing the de-bayer fast enough in the camera, answer they are not? I would have buffered the line data into two or three buffers and compressed the green, red, and blue as seperate lines or images, i.e. one large green image with interpolation and two small red and blue images without interpolation.

The other thing that might make no sense doing it that way is that the bayer filter makes high frequencies that requires a higher compression ratio, if you compress the seperation images the bandwidth should be lower total and the result quality higher. Did they make sample images using Bayer vs. seperation compression to check the bandwidth vs. quality on colored subjects of large area and low detail and high frequency high detail subjects of large area?

At any rate, in order to get the non-bayer data into my system for post one can now use workflow RED software to DPX to XnView (tm) to BMPx3+ to DANCAD87.EXE (tm) to 48bit NIP 103 (or to BMP dithered to XnView to DPX to film recorder or something else).

If I or someone else was to modify XnView (tm) to output my 48bit NIP 103 file type, then the input would be higher quality, likewise going from NIP103 to DPX again for doing something in other programs with some frames. I could help with this if someone knows the XnView (tm) code.

Better for RED to output my NIP 103 48bit format directly since it would take the extra steps out of the Workflow, my filetype is very simple, so it would only take them an hour or so, I could help write the code procedure, it would only be maybe 50 lines.


>>Note, Some tasks or programs used require Windows ME (tm) or Windows XP Home SP3 (tm) with the FreeDOS FAT32 (tm) disk mounted as a slave drive. Things may work better if all disks are formatted FAT32, which should work up to 2TB per disk.<<

UPDATE: DANCAD87.EXE (tm) now supports 16bit RGB 48bpp TIF files for import and export, so you can use REDCINE (tm) to de-Bayer the images and save the frames as 16bit TIF REDLog into the project folder my programs use. Then process RED ONE (tm) footage and do color correction, then save the edited frames back out with high quality as 16 bit TIF frame files.

 

[mrmuccy]

Graeme,

Anything you can tell me about the "wavelette based" compression would be appreciated. You say currently about 10:1. Could you give me that compression in a bits per pixel ratio?

thanks

 

[Graeme Nattress]

Edges are just fine, actually. We have a good demosaic. And the compression, precisely how we do it, takes care of the rest.

Well, we're talking about 24fps 4096x2304 RAW data 12bit to 28 or 36 MB/s.

Graeme