Welcome to our community

Be a part of something great, join today!

Register Log in
  • 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 :)

Adobe doesn`t seem to like 16bit tiffs?

I noticed this some time ago as well, on PS CS2. It's annoying to me, but no doubt most users would never notice it. I only noticed it because I was trying to generate a perfect 16-bit smooth ramp for some tests. That cannot be done in PS (for two reasons, one is the 15 bit issue, the other is that PS adds a 1-lsb dither, which actually is usually what you want to reduce banding).

It turns out that ImageMagick works just fine for what I needed, and that's what I ended up using.
 
  • Thread starter
  • Banned
  • #5
jbeale said:
I noticed this some time ago as well, on PS CS2. It's annoying to me, but no doubt most users would never notice it. I only noticed it because I was trying to generate a perfect 16-bit smooth ramp for some tests. That cannot be done in PS (for two reasons, one is the 15 bit issue, the other is that PS adds a 1-lsb dither, which actually is usually what you want to reduce banding).

It turns out that ImageMagick works just fine for what I needed, and that's what I ended up using.
Click to expand...


Which is pointless with a 16bit uncompressed image, because dithering the lsb won`t have any visual effect regarding banding or anything else, especially if then transcoded down to 8-10bit, because the dither will be lost during bit depth quantization. It is a little bit annoying. I hope Red can provide a demosaic`d raw sequence with no header (just raw raw raw) from Redcine, so I can get footage into in my own software, easily, without buying an expensive book on DPX format from smpte. I did send a PM to Rob about this, six months ago, but no reply :( .. I know, Ill try Deanan...
 
As far back as I can remember, Photoshop has always been using 15bit (signed shorts). They claimed that it was much faster and worth it.
 
You don't need an expensive book to make a simple DPX reader - it's header + packed 10bit data, and relatively simple to parse.

We're not currently likely to write our raw raw demosaiced data - it's just not that useful to 99.9% of people and we have enough challenge on our hands making development time for essentials.

Graeme
 
  • Thread starter
  • Banned
  • #8
Graeme Nattress said:
You don't need an expensive book to make a simple DPX reader - it's header + packed 10bit data, and relatively simple to parse.

We're not currently likely to write our raw raw demosaiced data - it's just not that useful to 99.9% of people and we have enough challenge on our hands making development time for essentials.

Graeme
Click to expand...

OK.
I didn`t expect it to be a priority, just wanted to know if it was a possible option (per Red philosphy on `options`), which it sounds like it isn`t.

SMPTE directed me to Amazon, but not a specific book. I haven`t been able to find DPX format information for free anywhere online. If I could, I wouldn`t have asked about raw raw. I thought the DPX would be packed with meta data etc, proprietory Red generated stuff etc etc

I understand what you`re saying, I just thought it would be very simple to implement ie, demosaic data, write it out. I would be happy to demosaic the data too if that was easier, and might be even better for me (although it may run 100x slower than yours, it would reduce file sizes by a third). Actually, there are times when I won`t need a NORMAL demosaic at all (now your confused). Having options is a very good policy.

I`d like to avoid needless transcodes, as I have my own systems of managing, storing and manipulating data, before Redcine or ? produces/conforms any final output. Redcine does look great (especially its no BS small size).

I think I did acknowledge it wouldn`t be used my most people, so we agree on that point, but 0.1% of 2000 people is, er, 2. If you sell 20000 Red Ones though, its, uummm, 20. Of those 20 people, half may do something new and interesting (or all, excluding myself of course), assuming 0.1% is accurate (which it could well be). One may be amazing. This won`t hurt Red , so maybe as a future, trivial to implement feature, it could be considered later on.

Regarding packed 10bit DPX, where do the other 2 bits of the 12bit sensor data go in this 10bit format? I was hoping to get linear 12bit RGB data out, not log? Is the sensor 10bit log?

Thought I`d get the request in early, and then again, with the message to Deanan, which did get this response. I know you`re busy, but don`t ask, don`t get, right? Red encourages asking, correct?

If you have an online link to DPX format details (or a text) that would be very very useful, as I`m trying to get in a position where I can hit the ground running in ? months from now. In the meanwhile I`ll examine a DPX file tonight. Does the file end with image data, or rags and tags?

I`m an artist, more than a programmer so I rarely interface with APIs (as I don`t keep up with the ever moving targets, of the seemingly infinite numbers of, often proprietory, standards), but I`ll have a bash at interfacing with your SDK when it arrives. We`re not all called David Newman (although quite a few people might be)

As a designer, I tend to use delphi in Windows, although I`ve started using C in linux (but I`m quite new to Linux, and rusty with C), both of which can make things difficult. 12/16bit RGB out would make things trivial for myself. My editing systems are not realtime, much closer to 3D render times, my output, often closer to animation than film.

I do appreciate your response. Don`t feel you have to respond to this message (unless its to PM DPX header info etc !!), you`ve made me feel guilty now for draining your resources, even though the Red development team open themselves up on this forum to questions and suggestions. Sorry my request was so silly.

I must be getting greedy, lazy or both. I shall use my belt on myself later till I repent.

thankyou, and good luck getting through these early development days, ronx.
 
Graeme Nattress said:
Sensor is 12bit, so for DPX we apply a curve when going to 10bit to preserve as much perceptually relevant precision as possible. Best for that is the REDLog curve, which was designed for that purpose and we can supply the "undo" curve to get back to 12bit linear.

http://www.cineon.com/ff_draft.php and http://www.kodak.com/US/plugins/acrobat/en/motion/support/dlad/cineonfileformat4.5.pdf are probably enough to get you working.

Hope that helps,

Graeme
Click to expand...

Thankyou very much. I`ll take a look. I still get confused about 12bit->10bit -> 12bit being lossless, but I don`t mean to slight your work. I do different things, and what you`re doing for traditional workflows IS dynamite. I was about to remove my reply above, as I`m p*ssed tonight which affects my judgement somewhat. best regards ronx.
 
It's not lossless in the sense that there is nothing lost, but it is in the sense that nothing important is lost. That's because in linear light data there are vastly more code values in the brightest stop (2048 code values) compared to the total amount of code values (4096) or are in the last 8 stops in total (256 code values) and hence we can "throw" away values in the brightest stops (via the log curve) and keep total precision in the darkest 8 stops, and not loose any precision that will negatively effect the outcome.

Graeme
 
jbeale said:
http://www.cineon.com/ff_draft.php

THere are also open-source programs like ImageMagick and Blender that can read & write DPX files, so you can just read their code if you prefer.

http://www.imagemagick.org/www/motion-picture.html DPX in ImageMagick
http://www.blender.org/development/release-logs/blender-242/high-dynamic-range-graphics/ ...in Blender
http://www.graphicall.org/builds/index.php various Blender builds
Click to expand...


Thats quick. Also thankyou very much. I haven`t used these, I think I may be suffering from neurological damage at the moment. Oh, I have used Blender. Um, don`t normally drink, I should stick to smoking peyote and some sun-dried coyote.. right I got research to do. fixing bayonet.
 
Graeme Nattress said:
It's not lossless in the sense that there is nothing lost, but it is in the sense that nothing important is lost. That's because in linear light data there are vastly more code values in the brightest stop (2048 code values) compared to the total amount of code values (4096) or are in the last 8 stops in total (256 code values) and hence we can "throw" away values in the brightest stops (via the log curve) and keep total precision in the darkest 8 stops, and not loose any precision that will negatively effect the outcome.

Graeme
Click to expand...

OK, thats what I thought. Relax, I`m happy. so I need to get up to speed on working with log curves. I won`t ask what type of curve function is used (spline, bezier, cat-rom etc). Is it general to generate a LUT for these conversions? I would imagine its slow without. I have seen general stuff online about colour, I`ll download the links now. thanx again
 
The log curve is of the form y=A * log(B*(x+C)). It's not a spline based curve at all. By altering A,B and C you can get a whole family of nice curves that obey the properties we need.

Graeme
 
Graeme Nattress said:
Sensor is 12bit, so for DPX we apply a curve when going to 10bit to preserve as much perceptually relevant precision as possible. Best for that is the REDLog curve, which was designed for that purpose and we can supply the "undo" curve to get back to 12bit linear.Graeme
Click to expand...



Where can we get that "undo" curve?
 
I need to tabulate and figure out how best to publish that data for you.

Graeme
 
You must log in or register to reply here.
Back
Top