John Anderson Posted February 18, 2013 Report Share Posted February 18, 2013 Hi, I'm wondering why a decision was made to process only JPEGs, instead of high-resolution DNG/TIFF files. It makes little sense to capture an image stack with, say, a 21MP sensor camera (i.e. a Canon 5D2) and then convert full-resolution DNG files to lossy jpegs, resulting in the loss of considerable image high-frequency information. Is it possible we could have a software update to take advantage of the superb image quality of current high-res cameras? KInd regards, John Anderson. Link to comment Share on other sites More sharing options...
cdschroer Posted February 19, 2013 Report Share Posted February 19, 2013 This is actually a more complicated question than it might appear. I'll break this down into a couple of parts, first describing why, even with processing jpegs, shooting RAW has huge advantages. Then, I'll give a high level explanation of some of the difficulties with creating a 16 bit pipeline for RTI (and some hopeful news about working with 16 bit files) 1. Why shoot RAW if you are going to process JPEGS? Shooting RAW gives you the highest quality image you can get from your camera, and it also affords you complete control and record keeping about how that image is processed. There's lots of information on line about RAW vs JPEG, so I won't get into that too much here, other than why you still want to shoot RAW for an RTI jpeg pipeline. First and foremost the RAW files you shoot should become your archive originals for your RTI capture set. This means when software does support a 16 bit workflow you can take advantage of it with images you have already shot. It also means any other use of those images in the future (say for the Algorithmic rendering) - you will have the highest quality images available. Also important is that by shooting RAW, you have complete control over the jpegs that get produced, so you will end up with jpegs that are most likely quite different than what would come straight out of your camera. For example, the sensors of most modern digital SLRs collect 14 bits per pixel per color channel of data (stored as a 16 bit file) Jpegs are 8 bits per pixel per color channel, so clearly you are losing a lot of information with a jpeg. In the camera the data from the sensor is turned into a jpeg and you have no control and no record of what was done. Generally the camera's processor will apply brightness, saturation and sharpening. If you follow CHI's recommended workflow, you shoot raw, convert to DNG, and make sure that you have not applied any transformations to the data except white balance, and possibly exposure compensation. It is important to stay away from sharpening. In addition, you have a complete record o the transformations in the xmp metadata contained in the raw file. You can also create a new set of jpegs with more or less exposure using exposure compensation and get a much better result than trying to manipulate jpegs. Your white balance based on a gray card will also be more correct than trying to white balance a jpeg. So even though you are creating an 8 bit file, you get to decide how to process the RAW for tht 8 bit file giving you a better result. 2. Why not just support a dng or tiff workflow all the way through the tools? We would love to do this, but it isn't as straightforward as you might think. First, the RTI tools are built with small amounts of money from grants, and also with some volunteer efforts. We have requirements to make the software run on both Mac and Windows, and also we need to maintain it. We have also chosen the GNU General Public License version 3 (GPL v3) as our license for the software. In order to make coding much easier and more maintainable all the code is written to libraries that allow the code to be recompiled for different platforms and we don't have to change the code. Further, the libraries give us all the support for lower level operations. The libraries we choose have to be compatible with us shipping the resulting software with the GPL v3. (they don't have to be GPL, they have to be compatible with that license - a completely separate and large topic) For RTIViewer for example, we use the QT libraries, and they don't support 16 bit (or didn't at the time we had the money to build RTiViewer. In addition, there are some limitations in support for dng. While Adobe makes available libraries to support dng under a range of liberal license terms, at the time we were building RTIBuilder, they only made these available for C and C++ code and that tool is written in Java. And finally, the actual building of the .ptm or .rti file is done by command line tools called "fitters." RTIBuilder manages all your files fr you, finding the light positions from the highlights on your sphere, doing record keeping, managing cropping, ets. but it doesn't actually build the finished file. Instead it calls these external programs to do so. the ptmfitter is from HP Labs and the executable is free for non-commercial use. The source code is not publicly available, and HP is not working on this software. It takes as input jpegs. The HSHfiter is available as open source, and someone could modify it to support tiff or dng as input, but there is no funding for such an endeavor at this point. Even if hshfitter was updated to support the 16 bit file formats, RTIBuilder would have to be modified to support those file type for most people to be able to take advantage of it, and as stated above that is a bigger project than you would want it to be. Some hopeful news. None of this means that the RTI pipeline won't support a 16 bit alternative in the future, just that it isn't in place now. Further we are discussing the possibility (no promises at this point) of suport a full 16 bit pipeline for the CARE tool now under construction. We would like to do that, but it is a question of time and budget as to whether it does get implemented. I hope that this information helps folks understand why they should still shoot RAW, and why the current pipeline is a jpeg one. Carla Link to comment Share on other sites More sharing options...
Taylor Posted February 20, 2013 Report Share Posted February 20, 2013 Is it possible to use the JPEG2000 lossless file format (.JPF, .JP2, or .JPX extensions) with RTIBuilder? I know this format isn't widely adopted, but it seems to have some good features and it also works with ImageJ software. Link to comment Share on other sites More sharing options...
cdschroer Posted February 20, 2013 Report Share Posted February 20, 2013 The real issue is that the fitters don't accept this format as input. RTIBuilder is managing the process of building RTIs and also doing the work of figuring out the light positions from the highlights on the sphere, but then the files are passed off to the ptmfitter or hshfitter. So there would have to be a plan for all the pieces for this to make sense. If we were going to rework the software my goal would be to support dng/tiff since the tiff format is much more widely adopted. Note that dng is an extension to tiff and that the core image data in a dng is stored as a tiff. If you want to know more about dng, you can find the spec for it here. There is a common misconception that dng is a proprietary format from Adobe, but it is not. It is an open standard with an international working group. There are no restrictions on writing to it or reading from it. psd *IS* a proprietary format, and that's a reason we don't recommend it for any longevity or archiving purposes. Camera RAW formats are also generally proprietary. We try to follow standards as much as possible, and also think about longevity of file formats, in addition to the technical merit. The number one consideration for file longevity is that you use an open format. We have adopted the principles espoused by the Library of Congress, Sustainability factors and high on that list is to use only open file formats, and formats that are widely adopted. This all has to be weighed with the cost of developing software, available software libraries with compatible licenses, and the cost of maintaining the software. Our best hope of a 16 bit pipeline remains the CARE tool - I can't promise this, but it is on the table. This is an active funded project, and if we can do this within the time and budget for the project we will. I will reveal that we are working on some bug fixes to RTIBuilder and we will be releasing a new version soon. We had a very small budget for this, so it is mostly bug fixes and a few small features, along with some performance improvements. We will announce the release in this forum, on the CHI facebook page, and on the CHI main website, as well as to subscribers to our email newsletter when the time comes. (in the next couple of months) Link to comment Share on other sites More sharing options...
John Anderson Posted February 21, 2013 Author Report Share Posted February 21, 2013 Hi Carla, Many thanks for your reply to my query. We already shoot in RAW and save to DNG format. I was merely wondering why RTI Builder didn't exploit the latter format for better image quality. I look forward to seeing a 16-bit software version. Kind regards, John Anderson. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.