Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

REDCODE RAW plugin for Photoshop?

Jim Arthurs

Well-known member
Joined
Dec 28, 2006
Messages
555
Reaction score
0
Points
0
Website
www.imageshoppe.com
Thanks to all for the wonderful footage coming in... and I'm sure with an additional 50 cameras out there in the world even more stuff will come our way.

My question, is there any still image format that truly gives EVERYTHING in terms of adjustment and processing latitude that the original .R3D file has to offer?

Even with the 16 bit .tiffs I see people like Mike Curtis qualifying the grade of his 16bit .tiffs, saying that there's more room to manipulate with the original file. Of course log files like Cineon and .dpx have choices burned in at some level as well and aren't the final answer.

When viewing stills, and for the eventual "stills-extracted-from-RED-footage" use of RED, what is the answer for the person wanting to have full manipulation flexibilty with RED footage at the still level?

Will it be REDCINE, and if so, will REDCINE be able to copy out a single frame and keep it native as a .R3D so the still could be passed on to an agency or other post house that doesn't have a RED or REDCINE?

Perhaps the answer (in addition to the absolute necessity of having REDCINE be able to clone-copy sequences or single frames to a new .R3D file) is a REDCODE RAW reader plugin for Photoshop. This would be whatever the latest de-bayer code and any other necessary input adjustments to bring the full range of the file into the standard curve and manipulation tools of Photoshop.

Just thinking out loud here...
 
This is an excellent idea! I can't think of a better solution for the ultimate in flexibility for both still extraction but also for motion work. A .psd sequence is something that I would love to have to work with. Being able to batch process with perhaps the ability to set an in and out frame marker would be wonderful. If REDCINE could have an export option of sequential raw frames and a Photoshop raw plugin, we would have everything needed.

EXCELLENT post Jim!
 
Thanks!

Not only is a cloned frame or short segment from a .R3D file the best quality, it's also the best choice for frugal file size...

I think this speaks to the needs of those who want to sell stock (both still and moving) shot with RED and also VFX houses... some of which might need only a handful of frames from a 4 gig .R3D file, but want the best possible quality and not work with pre-manipulated still sequences.

I remember forum talk long ago about being able to copy/clone segments of files, but don't know if this is still on the table or if it will work with single frames.
 
This would seem like a good time to request the REDExploder/REDCondensor again.

I would love to be able to split r3d files into a folder of stills and back for use with custom python stuff. Although I suppose this could be handled through commandline redcine operations. (i/o point export of r3d files without de/recompression.
 
It's possible to develop an R3D file so that the 16bit tiff contains more than enough room to have equal ability for post manipulation.

The other comments are, however, interesting, so we'll put them into the thinking pot!

Graeme
 
The other comments are, however, interesting, so we'll put them into the thinking pot!

The notion of exporting to a raw frame sequence is something I think I talked to you about last NAB. It has very significant value for conforming and finishing in that it would not require all shot footage to be on line at one time for conforming and color correction purposes. While it would still require the same processing power for live debayering as the wrapped movie file, it would cut down considerably on the storage required for the final conformed picture. It would also allow for simpler (and more familiar) file handling by the conforming and color correction software, assuming the metadata remained in place. Basically, the best of both worlds.
 
It's possible to develop an R3D file so that the 16bit tiff contains more than enough room to have equal ability for post manipulation.Graeme

Thanks Graeme.

Is the knowledge of how to exactly work REDALERT to get these results with 16bit files in the hands those with the camera, or written up somewhere? I've rarely (if at all) seen a posted .tiff where the poster wasn't somehow indicating that they could do a bit better or pull out more...

In addition, a .tiff or the like has a particular de-bayer approach baked in and that can't be fiddled with to the end users liking, if I understand the settings in REDALERT.

And as I said earlier, the 16 bit .tiff is massive in filesize compared to the size a single frame .R3D would be.

Selling stock footage on-line with downloads would be much easier in the native .R3D format, and insure the stock buyer that they are getting the best possible source, and would push the RED brand and codec into deeper market areas, IMO.

Of course there are times when you'd want to limit the quality or format of your stock footage for certain clients, but that's another topic altogether...

Finally, I suspect we'll see 3rd party solutions for de-bayering native .R3D files , but that has the potential to provide a variety of de-bayers that aren't to your standards and therefore mis-represent the quality of the footage...
 
Allowing the most flexible access to the raw data, in particular the choice to export and work with raw frames separately, would be most welcome.

In the DSLR world we've gotten used to a choice of different raw tools. I recall some story about how Nikon was "encrypting" white balance info in their raw .NEF format on their DSLRs, which caused some concern.
http://www.dpreview.com/news/0504/05042203nikonnefresponse.asp
 
Finally, I suspect we'll see 3rd party solutions for de-bayering native .R3D files , but that has the potential to provide a variety of de-bayers that aren't to your standards and therefore mis-represent the quality of the footage...

As I think about it, the upside of a third party approach could be a loader for Photoshop that perhaps uses a de-bayer approach that is very slow compared to what you'd use for sequences in REDCINE, but very high quality or has controls specific to still needs vrs. motion footage...

Again, just thinking out loud on all this... it's possible the current bayer strategies are both as good and as fast as possible (or in the process of becoming that) and such optimization for still work isn't needed...
 
would love to see the addition of Adobe's DNG format as an export option.
this I would think would solve a lot of issues regarding data access to the .r3d format
without having to release sdk's or trade secrets ect...

1. allows people access to raw data, so others could write or use other software
for raw conversion. (don't know how many times I've used lightroom to grade
timelapse shots from dslrs, as an example)

2. products like luster, resolve, ect... could add support for raw instead of just
using 10bit data

3. could be a big plus to projects trying to get green lit, offering insurance to the
bond company as having an open digital negative archival format.

4. having the full dynamic range available for processing

currently OpenEXR is the only export option that preserves the full floating
point data, but having the bayer data would be a great thing, as there are
dozens of companies writing raw software and as new products emerge
the quality of the debayer algorithims gets better and better... DXO optics
is one that makes large strides for example..


just a thought.


here are some links.
http://www.adobe.com/products/dng/
http://www.dxo.com/intl/photo/dxo_op..._5_coming_soon

-Andy
#1418
 
Thanks Andy, that's new info for me... that DxO Optics is some slick stuff, with lens corrections (vignetting, CA, distortion) for a wide variety of still glass. Boy would I like to see this in REDCINE down the road...
 
It's funny but since RED is really a DSLR taking x pictures per second, and it's recording RAW files, it's always seemed to me that finishing in a Photoshop-like app would be most appropriate for users, like me, who are in a more "low rent" situation. Coming from taking RAW images on a DSLR, it's a world I understand, and it also doesn't seem to have the quicktime gamma problems that Apple has right now.
Whether REDcine could best do that on it's own, or as a plug-in for Photoshop, I don't know..
 
As I think about it, the upside of a third party approach could be a loader for Photoshop that perhaps uses a de-bayer approach that is very slow compared to what you'd use for sequences in REDCINE, but very high quality or has controls specific to still needs vrs. motion footage...

Two years on from your post, and this is still not possible.

Surely this will be a must for the concept of the DSMC.
 
DNG

DNG

would love to see the addition of Adobe's DNG format as an export option.

R3D files are NOT RAW sensor data, like would be saved into a DNG file, so making a DNG file and then using a 3rd party de-Bayer program would probably de-grade the images over what the RED SDK can do because R3D is a wavelet format like JPG2000 not a true RAW format.

DNG has many problems since it need to be calibrated to the sensor AND Adobes de-Bayer code and so limits the quality of the end result, unless you use a de-Bayer that ignores the calibrations in the DNG file.

Its better to use the camera manfactures software in general to de-Bayer images from their cameras since they can tune their software for the issues their sensors have and the OLPF used.

R3D even more so since it is not RAW data but a special compressed form of RGB data where the green image has 4x the number of pixels as the red and blue images. RED Co. was going to have a RAW data port on RED ONE, but could not figure out how to make on at low cost, so their de-Bayer software evolved into a special case for processing their compressed RGB data that is in part processed in the camera and in part processed on the PC.

Making DNG files out of R3D would probably not give better results because you would need to try to synthesize something that looks like true RAW data from the RGB wavelet compressed images, so you would need to low pass filter the RGB data then do a blur then sample it in order to simulate the OLPF without getting artifacts from the wavelets that might show up under Adobe's de-Bayer software since it was desigined for "true" RAW data, or at least more RAW as most cameras process the sensor data before saving it to remove bad pixels and such...
 
It's possible to develop an R3D file so that the 16bit tiff contains more than enough room to have equal ability for post manipulation.

The other comments are, however, interesting, so we'll put them into the thinking pot!

Graeme

Great idea. My 2c to the pot.
 
Back
Top