Luminous Landscape Forum
Raw & Post Processing, Printing => Other Raw Converters => Topic started by: sperera on September 13, 2009, 11:12:14 am
-
will shooting JPEG-XR within a year or two as it starts to appear in cameras emancipate us from proprietary software to manange RAW files????
"Why? Because 100% of the information contained within a raw file can be encoded into a JPEG-XR file (no loss), and the manufacturer can decode the file in-camera, giving us the photographer the default colors and look intended by the manufacturer.
In this way you get the look the manufacturer intended without having to do any extra work. The camera delivers a fully useable (demosaic'ed) JPEG-XR file which may be 100% lossless for quality or lossy to save space (your choice). The JPEG-XR file, which is a "normal" image file will be transportable and useable just about anywhere a JPEG file is today.
There is one drawback to this approach, that only the pickiest of the picky will get held up on, and that's the fact that because your image gets demosaic'ed at the time it is captured, you will not be able to benefit from advancements in demosaicing technology as time moves forward. Today, if you open your raw file from 2000 in Lightroom 2.4, theoretically, it could look better than it would have had it been developed 9 years ago, because demosaicers are better today. In practice, though, this is not a significant concern."
...the above is quoted from Hasselbladinfo.com forum member Bradley Gibson
-
The author does not understand the essence of working with raw data. It has nothing to do with the lossiness of the in-camera processed images; actually, the old JPEG format does allow for lossless encoding (for example the Canon CR2 raw data is stored in this foprmat).
Recording raw data and processing it out of camera gives the photographer the chance to make adjustments based on decisions the camera could not make, and it allows for using different software tools.
The finished image out of camera (no matter in which file format) is the digital polaroid.
-
The author does not understand the essence of working with raw data. It has nothing to do with the lossiness of the in-camera processed images; actually, the old JPEG format does allow for lossless encoding (for example the Canon CR2 raw data is stored in this foprmat).
Blanket, unsubstantiated opinions about what others do or do not understand add little to the value of the conversation.
I stand by my statements.
-Brad
-
<deleted>
-
Blanket, unsubstantiated opinions about what others do or do not understand add little to the value of the conversation.
I stand by my statements.
-Brad
I hope we can get some good debate with this Bradley my friend.....the jpeg XR format sounds great to me!!!!!!!!!!!!
-
the jpeg XR format sounds great to me!!!!!!!!!!!!
The JPEG XR format is great. I guess it will take over the "presentation segment", i.e. what JPEG and TIFF is used for today. It could be used for encoding the raw data as well, lossily or losslessly, in smaller storage than the encoding methods are doing that today.
The topic of this thread is not if JPEG XR is better than JPEG. The topic is, if the concept of recording more or less raw data in camera and processing it off-camera remains superior to in-camera processing, or if higher quality recording of the in-camera processed images makes the raw data obsolate. The form of storing the data (encoding) is irrelevant in this question.
The question is, if negative film would become obsolate if the polaroid's quality were better.
-
The JPEG XR format is great. I guess it will take over the "presentation segment", i.e. what JPEG and TIFF is used for today. It could be used for encoding the raw data as well, lossily or losslessly, in smaller storage than the encoding methods are doing that today.
The topic of this thread is not if JPEG XR is better than JPEG. The topic is, if the concept of recording more or less raw data in camera and processing it off-camera remains superior to in-camera processing, or if higher quality recording of the in-camera processed images makes the raw data obsolate. The form of storing the data (encoding) is irrelevant in this question.
The question is, if negative film would become obsolate if the polaroid's quality were better.
Personally, I see the topic of this thread slightly differently. But for the moment, if the question is, "which gives superior results, in-camera or post capture processing", I am in complete agreement that the post-capture results will be at least equivalent but almost always superior, (provided users are willing to use the appropriate tool*) because of a number of factors including, computing horsepower, application sophistication and flexibility.
If we ask the question if the amount of difference in the finished file will be great enough that photographers will, in general, be willing to invest the extra time for these incremental improvements, my answer changes--working professionals, consumers and most amateurs are unlikely to see or see enough of a difference to care.
I believe that most will not be able to see the difference, or enough of a difference to warrant the traditional raw-camera-processing post capture workflow in a mature JPEG-XR world (years away, I am sure). I foresee the majority of photographers moving on from mosaic'ed formats and not looking back, especially sensor resoloutions as high as they are and still climbing.
So yes, calling it a 'convenience workflow' or a 'presentation format' is all fine--I believe it will become the defacto standard format people use to store, edit and share their files. There will remain people for whom mosaic'ed raw files are not obsolete.
The speculation on adoption is a just a prediction (ie. opinion, not fact) based on experience as I have seen it, nothing more.
-Brad
* using the appropriate tool properly for optimal image quality can also be a non-trivial task, if one is not technically experienced.
-
The JPEG XR format is great.
A question, and this is genuine ignorance, no agenda - I thought the XR spec was getting a fairly cool reception from camera manufacturers, etc due to the Microsoft patent situation? And yes, I do know about the MS Microsoft Open Specification Promise, but that has limitations - e.g., no sub-licencing, etc.
Sandy
-
Blanket, unsubstantiated opinions about what others do or do not understand add little to the value of the conversation.
I stand by my statements.
-Brad
You should stand way behind them; you're obviously the one who "doesn't understand". The whole point of shooting RAW instead of any flavor of file format processed in-camera (whether JPEG, JPEG XR, TIFF, or whatever else may be out there) is to have the flexibility of choosing any set of processing parameters in post instead of committing to any set of parameters in-camera. For applications where in-camera processing is "good enough", standard JPEGs are generally "good enough" as well. If standard JPEGs aren't good enough, then it's pretty unlikely that in-camera processing is going to be deemed desirable, either, and RAW/DNG is going to be the file format of choice. JPEG XR doesn't add enough value to either scenario to make a compelling argument for its existence.
RAW conversion isn't a slavery to be emancipated from; it's the freedom to process one's images as one pleases with whatever tool one deems best for the job. JPEG XR doesn't offer any meaningful advantages over RAW/DNG for those who choose to do their own conversion, and those who prefer in-camera processing (most likely press shooters with deadlines or the less technically astute) are unlikely to appreciate any great benefit from the image quality of JPEG XR over standard JPEGs. And as already pointed out, JPEG 2000 does everything JPEG XR does. JPEG XR is a solution in search of a problem.
-
Jonathan put it much batter than I could. Many of us want the freedom and flexibility to make our own decisions about processing. JPEG XR sounds to me analogous to a situation that might have happened back in film days, if some manufacturer claimed to have come out with the "ideal" film for all purposes, making all other films obsolete.
-
Sandy, that stuff not something I deal with. In any major effort like this there are many players, challenges, etc. I do not know how well or poorly JPEG-XR is being received. I hope it is well, but I do not know. It was ratified as an international standard (http://blogs.msdn.com/billcrow/archive/2009/07/29/jpeg-xr-is-now-an-international-standard.aspx) by the JPEG committee earlier this year--that's all I know at this point.
Jonathan put it much batter than I could. Many of us want the freedom and flexibility to make our own decisions about processing. JPEG XR sounds to me analogous to a situation that might have happened back in film days, if some manufacturer claimed to have come out with the "ideal" film for all purposes, making all other films obsolete.
Of course, JPEG-XR allows this--your camera files come out of the camera with some look to them. And I'm saying that I think most folks (but not all) will find this to be a good starting place for their files. I don't believe editing one's files from this point will not produce a noticeably inferior result to a purist raw workflow. Given the simplicity, I expect it'll be popular. But there's no way for me to prove any of that, it's just an opinion.
Eric, Jonathan, Gabor, I will take Jonathan's advice and will stand "way behind my statement" because according to you, I "obviously" don't understand. The thread is yours.
Take care, fellas,
-Brad
-
I am really sorry to have choosen too strong words in my first post and thereby started hunting Bradley from this thread. However, the essence remains unchanged: JPEG XR is an encoding and compression method. It's deployment may be meaningful as a substitute for the customary JPEG, as a substitute for the lossless JPEG or for any of the many different encoding/compression methods used by the cameras when storing the raw data. The question of encoding/compressing has nothing to do with the decision "raw or presentation image".
Neither the size, nor the quality of the legacy JPEG images is the cause for or against creating in-camera presentation images. Think of following: the modern, high-pixel count DSLRs create "fine quality" JPEG images in the size 4-10 MB (and more, I guess). For example one of the Canon 7D's images posted at Imaging Resources is 8 MB large. When resaving it in PS, quality 11 yields 6.8 MB and quality 12 yields 9.7 MB. In other words, that quality is at least as high as it is reasonable, probably higher, though the bit depth is a serious restriction. The JPEG embedded in a Canon 7D or 5DMkII raw file is about 2.5 MB. So, it does not depend on either the quality or the storage size. JPEG XR will save space at even higher quality, particularly it allows for more than 8bit depth.
The opening post started out with the question if JPEG XR will cause the elimination of raw image recording. The issue is not, which method to use when recording the data but which data gets recorded. There is no quality, which makes a presentation image equivalent to a raw image.
-
Of course, JPEG-XR allows this--your camera files come out of the camera with some look to them.
A RAW image doesn't have any "look"; the out-of-camera "look" depends totally upon which RAW converter one chooses and what default settings are chosen. When shooting RAW, you have almost complete freedom to choose any "look" you like, or try out several different "looks" to see which one is the most appropriate for the image. This is why most knowledgeable digital shooters use RAW. You have complete flexibility in processing the image in any way that you choose, and are guaranteed the availability of 100% of the sensor's dynamic range and color gamut.
And I'm saying that I think most folks (but not all) will find this to be a good starting place for their files.
On the contrary, there are two main classes of shooters who regularly use in-camera processing: media photographers who need the convenience of camera-produced JPEGS to meet their deadlines, and the technically clueless who either aren't skilled enough to operate a RAW converter and get good results or don't even know what RAW is.
I don't believe editing one's files from this point will not produce a noticeably inferior result to a purist raw workflow. Given the simplicity, I expect it'll be popular. But there's no way for me to prove any of that, it's just an opinion.
Au contraire, the experience of most photographers here is that it's not too hard to do RAW conversions that are noticeably superior to images processed in-camera. And exactly how is editing a JPEG XR image any "simpler" than editing a standard JPEG? The only advantage XR has is higher bit depth. You still have the disadvantages of a pre-baked color profile and white balance setting, and the irreversible loss of DR and gamut from the in-camera processing. The higher bit depth may make a newspaper photographer's job a bit easier, but they aren't typically looking for the absolute best image quality--meeting their deadline is the most important thing. For them, standard JPEGS are already overkill with regard to overall image quality; a Canon 10D can usually capture a better image than a typical newspaper press can print. And JPEG XR isn't going to help the technically challenged folks much; if you're too clueless to operate a RAW converter well, you aren't likely to be savvy enough to materially improve your images just because they have a few more bits per pixel.
The reason I and most other serious digital photographers use RAW is for the flexibility it offers when processing the image. No set of RAW conversion options is appropriate for every image, regardless of whether the conversion takes place in the camera or later on in a PC. JPEG XR does not change that fact, and as a result offers little benefit over standard JPEGs. JPEG XR may be useful as a format for presenting or archiving processed images, but touting it as a replacement for RAW workflow is simply ignorant.
-
I gave it some thought, and decided that rather than abandoning the thread, to respond to respectful discourse and to ignore the rest.
I am really sorry to have choosen too strong words in my first post and thereby started hunting Bradley from this thread.
Thank you Gabor, no harm done.
However, the essence remains unchanged: JPEG XR is an encoding and compression method. It's deployment may be meaningful as a substitute for the customary JPEG, as a substitute for the lossless JPEG or for any of the many different encoding/compression methods used by the cameras when storing the raw data. The question of encoding/compressing has nothing to do with the decision "raw or presentation image".
There seems to be a chasm here between the science and the practice. Every file format, including raw, is an encoding and compression (or not) method. So of course I must agree with your assertion that "JPEG XR is an encoding and compression method".
But in practice, people choose encoding and compression method (aka file format) based on their own personal weighting of factors such as quality vs. ease-of-use.
JPEG-XR promises to offer some new in-camera combinations (demosaic'ed floating point linear encoding, for example, with ICC presentation profile) which can allow the files to come with a default look set by the manufacturer, that the user can change in post without quality loss (modulo floating point precision), relative to a traditional mosaic'ed raw workflow, in post.
That's where I think we're disagreeing or misunderstanding one another.
-
JPEG-XR offers some new combinations (demosaic'ed linear encoding, for example, with ICC presentation profile) which can allow the files to come with a default look set by the manufacturer, that the user can change in post without quality loss (modulo floating point precision) relative to a traditional mosaic'ed raw workflow in post.
That's where I think we're disagreeing or misunderstanding one another.
This functionality of a default manufacturer "look" is already available from cameras that output DNG-format RAW files; the default conversion settings are set in-camera. The difference is that the manufacturer's "look" isn't baked in the way it is with JPEG XR. With DNG, you can change the white balance simply by altering the channel multipliers on the linear RAW data. With any camera-processed image format, you need to reverse-engineer the camera profile and tone curve to guesstimate the original linear values, tweak the channel multipliers, then re-apply the camera profile and tone curves. It's a much less exact process, and doesn't work as well as simply adjusting the RAW conversion white balance settings. You're replacing best practice with a kludgy approximation by using JPEG XR instead of DNG, and not gaining any real convenience benefit over DNG. What's the point?
-
JPEG-XR promises to offer some new in-camera combinations (demosaic'ed floating point linear encoding, for example, with ICC presentation profile) which can allow the files to come with a default look set by the manufacturer, that the user can change in post without quality loss (modulo floating point precision), relative to a traditional mosaic'ed raw workflow, in post
1. Already the last but one DNG format version, 1.2, allows for storing a complex set of information additionally to the raw data,which can be used by the raw processor to achieve certain "look". (The set of these tags together are called "camera profile".) The camera could store such data in the raw file, while the raw processor might use or discard it, under the user's discretion.
Adobe have provided sound reasoning why not to use ICC.
2. The definition of "raw image data" is not firm. Think of Canon's sRaw1, sRaw2 and mRaw - Canon calls them "raw", although they are far from the raw data; they are semi-processed. There are some good reasons to stick to the non-demosaiced data. Example: the very first stage of out-of-camera noise reduction should take place before or integrated in the demosaicing process.
I don't see any point in creating semi-raw but not directly presentable images (linear is not presentable). Either raw, or presentation version (both could be stored in JPEG XR format). Canon's semi-raw formats are nothing but space-saving features; they become obsolate with the very large capacity and cheap memory cards (they are anyway disastrous for those converting them in DNG format for workflow reasons).
-
Perhaps a bit OT, but why didn't JPEG-2000 catch on? My understanding is that the compression algorithms were substantially improved. Is it just the inertia of the status quo?
-
You can shoot a TIFF in nikon cameras still can you not? That's what Bradley is pretty much suggesting except now it will have a new name. Just don't try to recover blown highlights, open up deep shadows, try and achieve the ability to decide on an output colour space without lossy remapping, decide on a different sharpening or noise reduction to that done in camera.
Yes a 16 bit TIFF has a huge amount of information but it's still baked in, you are CHANGING the file rather than deciding on a new way to interpret the original 1's and zero's of the RAW data. I don't see that this would be any different. Just try recovering detail in a partially burnt out wedding dress from a TIFF, even a 16 bit one.
-
Perhaps a bit OT, but why didn't JPEG-2000 catch on? My understanding is that the compression algorithms were substantially improved. Is it just the inertia of the status quo?
I think this is for the same reason as most people looking for music, at least in their first quick search, do it in Youtube which is a video site. It's low quality audio is still good enough to listen to any audio clip. If you want more quality then you'll search for the MP3, but most people won't even go to that step.
Present JPEG is good enough to show your images on the net and even to print them. Why should users and the industry make any effort to change what already works fine enough?
I guess JPEG XR doesn't support undemosaiced data. That reason alone is enough to forget about it for quality digital captures.
BR
-
You can shoot a TIFF in nikon cameras still can you not? That's what Bradley is pretty much suggesting except now it will have a new name. Just don't try to recover blown highlights, open up deep shadows, try and achieve the ability to decide on an output colour space without lossy remapping, decide on a different sharpening or noise reduction to that done in camera.
Yes a 16 bit TIFF has a huge amount of information but it's still baked in, you are CHANGING the file rather than deciding on a new way to interpret the original 1's and zero's of the RAW data. I don't see that this would be any different. Just try recovering detail in a partially burnt out wedding dress from a TIFF, even a 16 bit one.
Ben, one of the differences between JPEG XR and 16-bit TIFF is the fact that JPEG-XR has a specification for dealing with high dynamic range floating point information. What this means in English, is black is 0.0 and white is 1.0 (instead of 0 and 65535 for tradtional 16-bit TIFF). It is possible to write numbers like 1.2 or -3.4 with JPEG XR (there's no standard way to do this with 16-bit TIFF). This means that IF you choose to edit and rewrite your data, in floating point format, it is quite difficult to clip your information.
Of course, you are still free to do a parametric description of your edits, just the way Lightroom does with all edits today (including JPEG), to retain maximum image quality, but the downside here is the portability issues (app B can't really know what all of app A's parametric edits mean until they're all standardized).
Both approaches have tradeoffs, but it's not such a lopsided question with this.
-Brad
-
Present JPEG is good enough to show your images on the net and even to print them. Why should users and the industry make any effort to change what already works fine enough?
Well, it is good enough with crappy presentation. As soon as more tone levels and higher dynamic range can be reproduced at prices for the masses, the old JPEG will have to go.
Think of modern TV's: contrast ration 2000:1 is already normal, and it seems to go up to 10000 or more very soon; the number of required levels too has to be increased.
I guess JPEG XR doesn't support undemosaiced data. That reason alone is enough to forget about it for quality digital captures
Would you have guessed, that the venerable, almost never used JPEG lossless compression (first version) supports mosaic data? Almost all compressed raw image data is in that format; it is a question of interpretation. JPEG XR allows for many different formats; everything, which can be done in JPEG can be done in JPEG XR as well, plus a lot more.
I saw size comparison between lossless JPEG, specifically DNG, and JPEG XR; the latter won by a wide margine.
-
As Gabor points out, it will support many things. The real question is, (like TIFF today), which and how many of the various options will end up being widely adopted by the industry?
For example, the floating point example I pointed out earlier is not a slam-dunk for hardware manufacturers. Floating point arithmetic is not something generally implemented in digital cameras today, so adding it represents an incremental expense. (JPEG XR's fixed point bit format was included to address this particular issue.) In the end, though, we simply have to hope that the industry "gets it" and supports the right flavor to ensure we as photographers get real benefits out of the new format.
Fingers crossed.
-Brad
-
Think of modern TV's: contrast ration 2000:1 is already normal, and it seems to go up to 10000 or more very soon; the number of required levels too has to be increased.
Definitely more. Panasonic's current 12th generation plasmas have a claimed contrast ratio of 40,000:1, and a dynamic CR of 2,000,000:1.
There seems to be an implication from Brad that a JPEG XR image can have the processed, punchy appearance of an in-camera conventional jpeg, yet still retain the potential for highlight and shadow detail recovery through floating point arithmetic. How does this work?
I'm reminded of a photographic expedition with my very first digital camera, the Canon D60. I travelled with a laptop. Downloaded all my RAW files to the laptop and converted them to 16 bit tiff using the default settings in Zoombrowser. As my laptop hard drive began to fill, I deleted the RAW files thinking that surely the 16 bit tiffs would contain all the information recorded in the RAW format. What a mistake!
-
There seems to be an implication from Brad that a JPEG XR image can have the processed, punchy appearance of an in-camera conventional jpeg, yet still retain the potential for highlight and shadow detail recovery through floating point arithmetic. How does this work?
This would not work. It is not the question of accuracy but the number or retained levels. The raw conversion, like contrast enhancement, but particularly the "gamma encoding" drastically reduces the number of tone levels; accuracy does not help on that.
JPEG XR may supersede the currently used lossless JPEG encoding for storing the raw data. However, the presentation version of an image is not an alternative for the raw data.
-
Ben, one of the differences between JPEG XR and 16-bit TIFF is the fact that JPEG-XR has a specification for dealing with high dynamic range floating point information. What this means in English, is black is 0.0 and white is 1.0 (instead of 0 and 65535 for tradtional 16-bit TIFF). It is possible to write numbers like 1.2 or -3.4 with JPEG XR (there's no standard way to do this with 16-bit TIFF). This means that IF you choose to edit and rewrite your data, in floating point format, it is quite difficult to clip your information.
Pardon me, but your ignorance is showing here.
Floating-point numbers still have maximum and minimum values, and have discrete steps between any given value and the next-highest or next-lowest value that can be represented, just the same as integers. 32 bits can only represent 2^32 discrete values, regardless of whether values are stored in those bits in an integer or floating-point format.
The only difference between floating-point and integer values is the interpretation of the binary data used to represent the numeric value. With integers, the interval between adjacent binary values is defined as 1. With floating-point numbers, the interval between binary values can be less than one or greater than 1. But the number of discrete values is still limited by the number bits used to represent the numeric value in either case. It makes no difference if you interpret those 32 bits as representing a value between 0 and 1 with an interval of 0.00000000023283064365386962890625 between adjacent discrete values, or a value between 0 and 4294967296 with an interval of 1 between adjacent discrete values. Using a floating-point format to store RAW or RGB values offers no advantage over a standard integer format.
The number of bits per pixel needed to cover the dynamic range of the sensor with acceptable precision is going to be exactly the same regardless of whether an integer or floating-point format is used to store the data. The same is true of image degradation caused by editing; you'll need the same number of bits in either format to prevent level and curve adjustments from causing unacceptable amounts of banding and posterization. Implementing a floating-point image format in camera would increase the hardware cost without offering any performance benefit. This is why no camera manufacturer has done so.
-
Pardon me, but your ignorance is showing here.
Floating-point numbers still have maximum and minimum values, and have discrete steps between any given value and the next-highest or next-lowest value that can be represented, just the same as integers. 32 bits can only represent 2^32 discrete values, regardless of whether values are stored in those bits in an integer or floating-point format.
The only difference between floating-point and integer values is the interpretation of the binary data used to represent the numeric value. With integers, the interval between adjacent binary values is defined as 1. With floating-point numbers, the interval between binary values can be less than one or greater than 1. But the number of discrete values is still limited by the number bits used to represent the numeric value in either case. It makes no difference if you interpret those 32 bits as representing a value between 0 and 1 with an interval of 0.00000000023283064365386962890625 between adjacent discrete values, or a value between 0 and 4294967296 with an interval of 1 between adjacent discrete values. Using a floating-point format to store RAW or RGB values offers no advantage over a standard integer format.
The number of bits per pixel needed to cover the dynamic range of the sensor with acceptable precision is going to be exactly the same regardless of whether an integer or floating-point format is used to store the data. The same is true of image degradation caused by editing; you'll need the same number of bits in either format to prevent level and curve adjustments from causing unacceptable amounts of banding and posterization. Implementing a floating-point image format in camera would increase the hardware cost without offering any performance benefit. This is why no camera manufacturer has done so.
This is simply incorrect; it would pay to check facts before calling someone ignorant.
There is a big difference between floating point and integer encoding. In integer encoding, in all parts of the range -- say 0 to 255 for 8-bit -- the spacing between levels is the same, be it the jump from 0 to 1 or the jump from 254 to 255. The dynamic range, which is the max signal divided by the quantization step at zero signal, is 255~2^8.
In floating point encoding, some number of bits is used to store a number (the mantissa) between zero and one to a certain degree of precision, and the remaining bits are used to store the exponent. Suppose again we take 8 bits, and devote 5 to the mantissa and 3 to the exponent. The mantissa is a number from 0 to 31 (2^5 possible values from the 5 bits); we get a number between zero and one by dividing by 32=2^5. Then the three bits of the exponent tell us multiply the mantissa by two to the power of the exponent, which in this example can be any number among {1,2,4,8,16,32,64,128}=2^n for n={0,1,2,3,4,5,6,7} (2^3 possible values for the exponent from the three exponent bits). Thus the gap between levels grows exponentially with the value of the exponent. At the low end, the spacing of levels is 1/32 between the first two encoded levels, 0 and 1/32; the gap between the two largest levels is 4 ((30/32)*2^7 and (31/32)*2^7). The dynamic range is the max signal divided by the quantization step at zero signal, which is (31/32*2^7)/(1/32)~2^12.
Floating point is similar in spirit to Nikon's lookup-table compression (sometimes called 'lossy compression' though I don't think this appellation does justice to the idea), in that the level spacing goes up as the average level goes up. This is justified in images, because photon shot noise rises with the illumination level, and once the noise is sufficiently larger than the level spacing, it is pointless to make the level spacing finer -- it just digitizes the noise more precisely without adding any accuracy to the data.
Floating point is useful for HDR because the exponent covers an extremely wide range of values, and the fact that level spacing grows at the high end is not so important.
If RAW data were stored in floating point, using 9 bits for the mantissa and 3 for the exponent, 12 bits could accommodate about 16 stops of DR. The 9 mantissa bits are sufficient to cover the typical S/N ratio of DSLR's in the highest stop at the lowest ISO, which in all current cameras is less than 2^9, and therefore prevent posterization. But then again, people would have to give up their cherished myth that all those levels in the highest stop of integer encoded data mean anything. Michael's essay on ETTR is wrong on this point.
-
Thank you for your comprehensive reply, Emil. We chose s10e5 (one sign bit, 10-bit mantissa and 5-bit exponent) partly for just the reason you mention -- to cover the anticipated DR. For very demanding (ie. future or very high dynamic range applications IEEE 754 32-bit float is supported, with 23 bits of mantissa (s23e8).
There seems to be an implication from Brad that a JPEG XR image can have the processed, punchy appearance of an in-camera conventional jpeg, yet still retain the potential for highlight and shadow detail recovery through floating point arithmetic. How does this work?
To deal with the clipping problem, let me use integer numbers, since they are better understood. The simple answer is to not use all the values from 0 to 65536 (in 16 bit integer) to encode all values from black to white. If you instead decided to consider, say, 16 to be black and 240 to be white, you would be able to do some limited amount of processing on the file, and numbers going beyond 240 or below 16 would retain their distinct values (ie. Would not clip). This is effectively what the Fixed Point formats are, although the actual technique is a bit more sophisticated.
Floating point allows us to provide a very large range of values below black and above white for a reasonable economy of bits. For a 12 or 14-bit ADC, taking into account a real noise floor, the full range of data can be encoded in to float16 very well. For best quality 16-bit ADC applications, float16 would still serve well, but some will undoubtedly want couple more bits in the mantissa, so for those applications float32 serves very well, and will completely encode all the information captured by forseeable devices over a HUGE dynamic range (many orders of magnitude larger than any devices available today).
How the data beyond black or white might get used is a whole 'nother can of worms, but hardware is available and on the horizon which is able to take astonishing advantage of this information.
At the very least, the information is not clipped and thus can be later recovered and utilized in subsequent edit sessions or when outputting to a different device (eg. screen vs. printer, for example).
-
How the data beyond black or white might get used is a whole 'nother can of worms, but hardware is available and on the horizon which is able to take astonishing advantage of this information.
At the very least, the information is not clipped and thus can be later recovered and utilized in subsequent edit sessions or when outputting to a different device (eg. screen vs. printer, for example).
Interesting! On my travels I have found that a surprising number of fellow travellers sporting DSLRs shoot in jpeg mode. Once, many years ago on a trip, I found I was quickly running out of compact flash memory and switched from RAW mode to jpeg-fine mode. Despite my deliberately underexposing in order to retain full highlight detail, I found I had many shots, particularly of waterfalls, with blown highlights which I could do nothing about. I was generally disappointed with the results and have used RAW mode ever since.
On occasions I have shot RAW + JPEG just to see if there was any in-camera processing of the RAW image which was more pleasing than what I could achieve easily myself converting in ACR and further processing in Photoshop, but there wasn't, so no point except perhaps a saving of time when one wants a quick result.
A quick result that looks good, but with the potential to recover the full detail recorded by the sensor, would definitely be worth having.
-
This is simply incorrect; it would pay to check facts before calling someone ignorant.
There is a big difference between floating point and integer encoding. In integer encoding, in all parts of the range -- say 0 to 255 for 8-bit -- the spacing between levels is the same, be it the jump from 0 to 1 or the jump from 254 to 255. The dynamic range, which is the max signal divided by the quantization step at zero signal, is 255~2^8.
In floating point encoding, some number of bits is used to store a number (the mantissa) between zero and one to a certain degree of precision, and the remaining bits are used to store the exponent. Suppose again we take 8 bits, and devote 5 to the mantissa and 3 to the exponent. The mantissa is a number from 0 to 31 (2^5 possible values from the 5 bits); we get a number between zero and one by dividing by 32=2^5. Then the three bits of the exponent tell us multiply the mantissa by two to the power of the exponent, which in this example can be any number among {1,2,4,8,16,32,64,128}=2^n for n={0,1,2,3,4,5,6,7} (2^3 possible values for the exponent from the three exponent bits). Thus the gap between levels grows exponentially with the value of the exponent. At the low end, the spacing of levels is 1/32 between the first two encoded levels, 0 and 1/32; the gap between the two largest levels is 4 ((30/32)*2^7 and (31/32)*2^7). The dynamic range is the max signal divided by the quantization step at zero signal, which is (31/32*2^7)/(1/32)~2^12.
I'm aware that the exponent can be varied in a floating-point number format. If such a floating-point encoding scheme is used for RAW data, those bits are completely wasted. All ADC converters have a fixed dynamic range and an integer output. Converting the RAW output to a floating-point format with a variable exponent is pointless, because there is only one optimal exponent value: 1. If the exponent value is greater than one, then you must either throwing away information by mapping multiple input values to a single output value, or else using an unnecessarily large number of bits to encode a RAW value. If the exponent value is less than one, then you are wasting bits specifying values to the right of the decimal point that are always zero--just the same as if you padded 12-bit values with zeroes to make them 16-bits.
You're also ignoring the fact that regardless of how many bits are devoted to the mantissa vs the exponent, you can't escape the fact that 32 bits can only represent 2^32 discrete values, regardless of whether those values are interpreted as integers or floating-point numbers. And as long as ADCs linearly output integer values, converting to a floating-point RAW format is at best a break-even proposition regarding the number of bits required to encode a given dynamic range, and is most likely to be less efficient--more bits needed to encode the same information. What's the point?
-
I'm aware that the exponent can be varied in a floating-point number format. If such a floating-point encoding scheme is used for RAW data, those bits are completely wasted. All ADC converters have a fixed dynamic range and an integer output. Converting the RAW output to a floating-point format with a variable exponent is pointless, because there is only one optimal exponent value: 1. If the exponent value is greater than one, then you must either throwing away information by mapping multiple input values to a single output value, or else using an unnecessarily large number of bits to encode a RAW value. If the exponent value is less than one, then you are wasting bits specifying values to the right of the decimal point that are always zero--just the same as if you padded 12-bit values with zeroes to make them 16-bits.
You're also ignoring the fact that regardless of how many bits are devoted to the mantissa vs the exponent, you can't escape the fact that 32 bits can only represent 2^32 discrete values, regardless of whether those values are interpreted as integers or floating-point numbers. And as long as ADCs linearly output integer values, converting to a floating-point RAW format is at best a break-even proposition regarding the number of bits required to encode a given dynamic range, and is most likely to be less efficient--more bits needed to encode the same information. What's the point?
I'm sorry, Jonathan, that is also incorrect.
When writing imaging data in floating point format, one does not simply encode the integer value using floating point format!
Floating point numbers do not work well with padding--in fact, most implementations of floating point arithmetic (including Intel's processors) will penalize you performance-wise if you try to do this--in fact, in certain circumstances, padding may not even work at all. Floating point numbers should be normalized for best performance and precision.
Allow me to illustrate one common way imaging information is encoded into floating point numbers, applicable to this thread (ie. the way it's done for JPEG-XR floating point formats). The saturation (max) output of the sensor is mapped to 1.0 (or 0.9999....) When equating the integer 16-bit values you are familiar with to floating point values you would see the following: (Note that the exponent takes on a range of values, in particular, negative values. This does not mean the number is negative, only that the value is specified at very high precision. This is what gives floating point representations their capability to render shadow detail at exceptionally fine fidelity.)
16-bit Integer => Floating point value / Exponent value
65535 => ~1.0 / 0
32768 => 0.5 (1/2) / -1
16384 => 0.25 (1/4) / -2
8192 => 0.125 (1/8) / -3
...
4 => 0.0000610351... (1/16384) / -14
2 => 0.0000305175... (1/32768) / -15
1 => 0.0000152587... (1/65536) / -16
0 => 0.0 / -127
The above works because when working in linear space, as sensors do, double the photons gives you double the numeric value, and half the photons gives you half the numeric value.
I'll leave the topic of why the exponents are these particular values for another discussion--just know that this is an international standard (IEEE 754 if you wish to look it up)--for our purposes here, it is easy to see that a variety of exponents are used to encode normal values from the sensor ranging from normal black to normal white. There is no padding and the number of values from 0 to 1 is not limited to the number of bits in the mantissa.
When the manufacturer makes the proper calibrations for non-linearity of the ADC, the noise floor of the sensor, etc., the signal can be encoded quite nicely into a 16-bit floating point value ranging from 0.0 to 1.0 for almost every consumer device, and certainly into a 32-bit floating point value. And the fact that 0.0 and 1.0 are not the limits of the range of numbers that can be encoded, it becomes very difficult for users to clip their data in the course of performing normal imaging operations.
As I have been saying throughout this thread, giving users the ability to manipulate their data, without needing to understand or worry about side-effects like clipping was one of the design goals of JPEG-XR.
-
I'm aware that the exponent can be varied in a floating-point number format. If such a floating-point encoding scheme is used for RAW data, those bits are completely wasted. All ADC converters have a fixed dynamic range and an integer output. Converting the RAW output to a floating-point format with a variable exponent is pointless, because there is only one optimal exponent value: 1. If the exponent value is greater than one, then you must either throwing away information by mapping multiple input values to a single output value, or else using an unnecessarily large number of bits to encode a RAW value. If the exponent value is less than one, then you are wasting bits specifying values to the right of the decimal point that are always zero--just the same as if you padded 12-bit values with zeroes to make them 16-bits.
Apparently my previous post was not sufficiently clear. If you are hung up on translating integer ADC output to floating point notation, think of it this way. Returning to my example of partitioning 8 bits into 5 mantissa bits and 3 exponent bits (and correcting some math errors), simply don't divide the mantissa by 32. The idea of floating point is not contingent on the mantissa being a number between zero and one. One now has the mantissa as an integer from 0 to 31. Add 32 to get a number from 32 to 63. Multiply by 2^exponent; the three bit exponent takes values from 0 to 7. So I have just supplied an algorithm to take 8 bits and encode numbers for which the range is from 32*2^0=32 to 63*2^7=8064, or nearly 13 stops from 8 bits. One achieves this through the gap in the quantization step growing expoentially in concert with the growth in the exponent. For instance, the quantization step is one for the encoded values from 32 to 63; two for the encoded values from 64 to 126; four for the encoded values from 128 to 252; and so on. This is not ideal for photographic image encoding (it does not achieve maximal data compression) but it is better than straight integer encoding, and it is sufficient if in all parts of the encoded range, the noise is sufficiently larger than the quantization step. Ensuring that this is the case is an issue of how to partition the bits between mantissa and exponent, and the well depth of the pixels whose data is being encoded.
The exponent is an instruction to do a bit shift by the amount specified by the exponent. This is fine if the low order bits of large encoded values are irrelevant. They are in digital imaging, because of photon shot noise. Floating point encoding sets some number of least significant bits to zero, depending on the overall level, rather than the recording the random values they would take due to photon shot noise. The difference is insignificant.
You're also ignoring the fact that regardless of how many bits are devoted to the mantissa vs the exponent, you can't escape the fact that 32 bits can only represent 2^32 discrete values, regardless of whether those values are interpreted as integers or floating-point numbers. And as long as ADCs linearly output integer values, converting to a floating-point RAW format is at best a break-even proposition regarding the number of bits required to encode a given dynamic range, and is most likely to be less efficient--more bits needed to encode the same information. What's the point?
The point, as I tried to make clear, is that those 2^32 nonlinearly encoded values are spread over a much larger linear range. If the values in the linear range that are skipped over are not discernable due to noise in the system, it is just as well they were left out. As I pointed out in my initial post, Nikon's "lossy" compression works to the extent that it is properly implemented because of this fact.
-
This would not work. It is not the question of accuracy but the number or retained levels. The raw conversion, like contrast enhancement, but particularly the "gamma encoding" drastically reduces the number of tone levels; accuracy does not help on that.
JPEG XR may supersede the currently used lossless JPEG encoding for storing the raw data. However, the presentation version of an image is not an alternative for the raw data.
I'm sorry, Gabor, it is not my intent to be contrarian, but I feel I must correct you here on that bit of misinformation.
It does work--with floating point data, we leave the "gamma encoding" to the presentation profile. Do a demosaic with a gamma of 1.0, and add your display gamma in on presentation. The image data retains maximum fidelity and gains benefits from being edited in linear space rather than in gamma 2.2/2.4.
In short, it works just fine.
-
It does work--with floating point data, we leave the "gamma encoding" to the presentation profile. Do a demosaic with a gamma of 1.0, and add your display gamma in on presentation. The image data retains maximum fidelity and gains benefits from being edited in linear space rather than in gamma 2.2/2.4.
Ray's suggestion was
retain the potential for highlight and shadow detail recovery through floating point arithmetic
The gamma curve is the last one; there is "S" curve, specific contrast enhancement, highlight- and shadow recovery, black point, white point. In order to be able to do that, the entire spectrum of the demosaiced linear data must be retained.
The next step would be not to perform the color space conversion but to leave the data in the camera's color space, and let the presentation do the conversion depending on the medium. This is logical, isn't it? (The gamma curve depends on the color space, but if that is not fixed, then the color space too can be changed). Your image shot in raw could be presented much better on a monitor with ProPhoto capability; I am sure such monitors will come. This would allow even for the color adjustment (like it is being done by Picture Style or Camera Profile). Adjusting saturation and brightness directly at the presentation is only natural.
There are two problems with this:
1. When working on an image for example in PS, previous steps must be "fixed" in order to make certain adjustments. You can't make for example enhancements by curves or on selected colors without knowing the result of the previous steps.
2. I am pretty sure, that most photographers would not publish their worthy images in this quasy raw format, which is fully open for further adjustment.
-
Ray's suggestion was
retain the potential for highlight and shadow detail recovery through floating point arithmetic
The gamma curve is the last one; there is "S" curve, specific contrast enhancement, highlight- and shadow recovery, black point, white point. In order to be able to do that, the entire spectrum of the demosaiced linear data must be retained.
I don't know how to explain it any more clearly than I have. There is no problem making contrast (or hightlight or shadow recovery or black point or...) adjustments in linear space. One's editing program simply views the results after gamma adjustment, in real time.
The next step would be not to perform the color space conversion but to leave the data in the camera's color space, and let the presentation do the conversion depending on the medium. This is logical, isn't it? (The gamma curve depends on the color space, but if that is not fixed, then the color space too can be changed). Your image shot in raw could be presented much better on a monitor with ProPhoto capability; I am sure such monitors will come. This would allow even for the color adjustment (like it is being done by Picture Style or Camera Profile). Adjusting saturation and brightness directly at the presentation is only natural.
I can think of only two reasons to avoid a color space conversion: i) destination color space is insufficient for the required purposes ii) destination bit format would cause an unacceptable loss in fidelity (precision). We believe that a floating point representation with the same primaries as sRGB addresses both issues. If a users disagrees, the traditional pixel formats in which you can leave the data unmolested remain available.
"Only natural"? I don't really know what to make of 'only natural', but let me say that in practice, the techniques I've described work just fine. If you've viewed or edited a JPEG image file in Vista or Windows 7 you've already been using the techniques I've described. This technique has been shipping in Windows for the past 2 1/2 years, worldwide. I know, because I led the team that replaced the Windows XP imaging pipeline--we spent four years developing the hardware-accelerated floating point imaging pipeline and made sure it would work with JPEG-XR, and even with legacy file formats (ie. JPEG, TIFF). So it is hard to say that these ideas don't work, because the world is already using them!
There are two problems with this:
1. When working on an image for example in PS, previous steps must be "fixed" in order to make certain adjustments. You can't make for example enhancements by curves or on selected colors without knowing the result of the previous steps.
2. I am pretty sure, that most photographers would not publish their worthy images in this quasy raw format, which is fully open for further adjustment.
1) Yes, when re-editing and baking those changes into the bits you will accumulate error based on the precision of the pixel format. Of course! This is true for any non-parametric edit in any format--this is no exception--except that those concerned can use pixel formats with very high precision (low error). Further note that JPEG-XR does not prevent anyone from using parametric edits, should they wish to, but then portability issues become the primary concern. There is no free lunch!
2) This argument sounds like you are saying that photographers won't like it because the format is too good! To paraphrase my understanding of this point: "Having one's digital files available in all their fidelity for others to edit might be too scary for people." Perhaps, but I don't think most photographers are relying on the limitations of a pixel format to protect their intellectual property--typically, they publish a low-resolution preview. Indeed, by the amount of FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt) being spread in this thread, it is hard to imagine that the technology is well-enough understood by the general population for "security by pixel format" to be the case.
Bottom line is this: People needed to know and understand too much to edit their images without damaging them. We did our best to develop an improved tool for photographers which could work very well at helping people have i) better quality images and ii) a simpler workflow without any additional effort, knowledge or special training on their part.
No one is claiming the technology saves babies (though there may be applications in the medical field...), solves world hunger or is perfect in any other way. Simply that special, third party tools should no longer be NECESSARY to get the most out of your files.
At the risk of repeating myself (again): you still want 3rd party tools? Mosaic'ed data? Parametric edits? 16-bit integer? Clipping? 8-bit integer for security reasons? No problem--to the best of my knowledge JPEG-XR has not taken away any of your choices, but rather offered additional, and we feel, more effective ones.
The JPEG committee met in Lausanne (http://www.jpeg.org/newsrel19.html) back in 2007 and seemed to agree--they began the process which has since made this technology an international standard. That seems to be a pretty good endorsement in my book.
Gabor, I do respect your knowledge and expertise in the integer raw domain. I have seen you take countless hours to help others understand with graphs, charts, screenshots, in numerous posts to help clarify misunderstandings and put solid information out there (although, at times, I personally wish the presentation was more civil). But in this thread, there has been too far much supposition and speculation masquerading as fact.
I feel the information is now out there, and you and others may choose to accept it or not, but that is, of course your/their choice. For me, though, the theme in this thread that "it won't work" has run its course.
-
For me, though, the theme in this thread that "it won't work" has run its course.
Yes, lets all agree that it will work. However, "will work" and "is a good idea" are different. I think perhaps you skipped over the floating point issues a little fast - the thing is, floating point is not an efficient way to code information if your information has a fixed range. Practical example, because all the claims and counterclaims above without any examples was giving me a headache:
If you have an image, and you gamma encode to 2.0 (2.0 just to make the math easier), the mid-tone stop of that image is from 0.17 to 0.25 on a 0-1 scale. Using good old fashioned 16 integer encode, you get of the order of 4794 discrete levels within that mid tone stop.
However, if you use the s10E5 encoding, and assuming I understanding it correctly, the exponent doesn't change, so you get about 655 discrete levels. That's about 15% of the resolution in the mid tones for the float encoding vs the integer encoding. Given the choice between more mid-tone resolution, and the ability to encode a pixel value so small it will never exist, I, and I think most photographers, will take the mid tones.
Now I may have punched the wrong key on my calculator somewhere in there, but the principle applies pretty generally; the DNG format has had the ability to use float encoding since it was introduced. But I've never seen a single DNG image that used float; it's just not an efficient way to use bits for storing images. Float is of course a good way to process images, but that's a different situation.
Sandy
-
The most efficient use of levels for RAW encoding would be to perform a gamma transform with gamma=2.0, except for a linear portion at the low end (similar to the linear segment of the transform used in sRGB and Lab), and then use integer encoding. This linearizes the shot noise so that in each part of the range, the noise dithering is a fixed number of integer levels. At low levels one wants to account for the change in the dithering due to read noise; and also allow negative levels, again because of the read noise, which would be difficult with the gamma transform.
Floating point, for which the quantization step grows exponentially with the level, indeed uses too many levels at the low end, as Sandy says.
-
2. I am pretty sure, that most photographers would not publish their worthy images in this quasy raw format, which is fully open for further adjustment.
And musicians would not publish their music in CD quality. Oh, wait...
-
Present JPEG is good enough to show your images on the net and even to print them. Why should users and the industry make any effort to change what already works fine enough?
Two reasons: 1. File size - Even though disk space is cheap these days I would very much appreciate smaller files out of my Canon 5D Mark II. 2. More than 8-bit/channel. So, personally I would really like to have the option to use a better file format.
-
And musicians would not publish their music in CD quality. Oh, wait...
The technology of music and photography have very much common, so this is a splended analogy, for sure. Btw, in which shop do you get sheet music (gedruckte Noten) and the master recording with the CD?
-
I don't know how to explain it any more clearly than I have. There is no problem making contrast (or hightlight or shadow recovery or black point or...) adjustments in linear space. One's editing program simply views the results after gamma adjustment, in real time
There is no need to explain it at all. The technical capability was not the question; if you go back in the posts, you find that I suggested already at the beginning, that JPEG XR be used for the raw data encoding. Furthermore, it is unquestionably better for storing the presentation version than the legacy JPEG.
However, you went very far from that point. What you are suggesting is, that a semi-raw format be used for the presentation, instead of the currently used final format. This is not the question of the technical possibility; it is the question of basic attitude:
do photographers want to distribute their images in a semit-raw format or do they want to have the final say about their appearance?
If you find many photographers, who want to go that way, then your position was the right one. My opinion is, that we may see JPEG XR two times: once for storing the raw data, and once for storing and distributing the presentation version in final form.
-
The point, as I tried to make clear, is that those 2^32 nonlinearly encoded values are spread over a much larger linear range. If the values in the linear range that are skipped over are not discernable due to noise in the system, it is just as well they were left out. As I pointed out in my initial post, Nikon's "lossy" compression works to the extent that it is properly implemented because of this fact.
So what? What you're advocating here is a form of lossy compression, a gain achieved by quantizing multiple large integer values to the same floating-point value. In practice, there is no difference between doing that and using standard RGB integer values with a defined gamma/TRC curve. It's nothing more than an alternate method of gamma encoding. As such, it is just as undesirable to use JPEG XR as a RAW format as any other integer-based RGB file format with a gamma >1.
Let's go back to the question posed in the topic title--can JPEG XR eliminate the need for RAW conversion? Definitely not. Before the linear RAW data from the sensor can be presented as an image, a bunch of stuff needs to be done to that data. At a minimum, we must:
1. Demosaic the RAW data to linear RGB.
2. White balance (scale the demosaiced RGB channel values so that neutral colors have equal R, G, and B values).
3. Convert to an RGB editing space (which involves changing the TRC and using some sort of camera profile to convert from demosaiced RGB values to the appropriate destination space RGB values).
In-camera processing rarely does any of these tasks optimally. The best demosaic algorithms need more computing horsepower than is typically stuffed inside a camera. Shooting conditions can easily fool automated white balance sensors, and often the preferred white balance chosen for creative reasons rather than absolute technical accuracy. And given camera-to-camera variation, being limited to the standard factory color profile baked into the camera firmware is usually far from ideal. On top of that, there's the issue of level and curve adjustments that are best done on an image-by-image basis--no camera firmware is good at doing custom curve adjustments.
RAW/DNG is the closest thing you can get to the unadulterated original data straight off the sensor. Current lossless compression algorithms can shrink standard RAW file size to something fairly comparable to JPEG XR, but with no adulteration of the RAW data. The whole point of shooting RAW is to have the unadulterated RAW data to work with, so that you don't lose any DR or color gamut from in-camera processing, and have maximum flexibility to edit and adjust the image without causing unacceptably high levels of artifacts. JPEG XR doesn't change that one bit.
-
Quick replies:
All, firstly I would like to say how much I appreciate the change in the tone of this discussion from where it started out to a much more respectful exchange. I firmly believe forums such as this one should be a place of coming together and exchange of ideas. When we discuss thoughts, opinions and ideas and yes, even disagree on some things but do it respectfully, I think that all participants can come away enriched from the experience.
Sandy, a JXR 16f encoding would provide 1024 levels for each stop encoded. Values are determined starting at the sensor saturation point (mapping to 1.0) and halving the numeric value for each stop. As Emil points out, the numeric range of these 1024 levels is not constant, but the precision does remain proportional to the relative numbers of photons being captured on a per-stop basis.
Sandy, Emil, it may have too much fidelity in the shadows, but overall being able to avoid clipping seems like a bigger fish. That is the one we went after. In fact it was not the efficiency of the encoding or the excess fidelity in the shadows that caused the most controversy, it was the 'only' 1024 levels in the highlights (the corollary). Still, seems OK, and there's always 32f, or 16i if not.
Gabor, Agreed that it's all a bet on what photographers want. Only time will tell if it catches on as envisioned, as two distinct types of files as you've suggested, or even at all.
Best regards,
-
So what? What you're advocating here is a form of lossy compression, a gain achieved by quantizing multiple large integer values to the same floating-point value. In practice, there is no difference between doing that and using standard RGB integer values with a defined gamma/TRC curve. It's nothing more than an alternate method of gamma encoding. As such, it is just as undesirable to use JPEG XR as a RAW format as any other integer-based RGB file format with a gamma >1.
It's not lossy compression when there is no information content to using a larger number of levels; quantizing noise is never an efficient use of bit depth, does not increase the informatino content of the image data, and linear integer data encoding does a lot of noise quantization over most of the range. There is also a big difference between using nonlinear encoding on the output of a RAW conversion vs using it on using it on the RAW data itself.
I am not advocating the use of floating point; as I mentioned above, the most efficient use of bit depth is to use a gamma=2.0 encoding together with a linear segment at low levels. Similar to Nikon's original compressed NEF format. But even though floating point is not optimal, it can achieve better data compression without loss of image information content than integer encoding without gamma transformation. And it was your incorrect statement that there was no distinction (and the uncivil tone in which it was offered) that I responded to in entering this thread.
Let's go back to the question posed in the topic title--can JPEG XR eliminate the need for RAW conversion? Definitely not. [snip]
Agree with what you had to say here.
-
We chose s10e5 (one sign bit, 10-bit mantissa and 5-bit exponent) partly for just the reason you mention -- to cover the anticipated DR.
In my understanding having a higher DR is not necessarily synonymous with higher SNR all the way. In general floating point would provide higher SNR except at the highest signal levels. To use your numbers, the comparison of 16 bit uniform quantization and s10e5 (one sign, 10-bit mantissa and assuming hidden bit, and 5-bit exponent) would be:
16-bit-Uniform-Quantization: DR = 90 dB, and SNR=98 dB (sinusoidal input wrt quantization noise).
Floating-point, s10e5: DR = 253 dB, and SNR = 74 dB (sinusoidal input wrt quantization noise).
DR for floating-point is much higher. As far as SNR is concerned the floating point will have higher SNR if the signal intensity is below the maximum by more than 24 dB.
If you have chosen s11e4 you would have gotten 80 dB SNR, but, then the DR would have reduced to 163 dB.
-
Agree with what you had to say here.
I guess we'll have to agree to disagree on that one, and see what happens.
-
It's not lossy compression when there is no information content to using a larger number of levels; quantizing noise is never an efficient use of bit depth, does not increase the informatino content of the image data, and linear integer data encoding does a lot of noise quantization over most of the range. There is also a big difference between using nonlinear encoding on the output of a RAW conversion vs using it on using it on the RAW data itself.
Whenever you throw information away (which is what you are always doing when you map multiple input values to a single output value) you are not improving the fidelity of the digitized data. If the data you throw out is mostly noise, then fidelity is not being compromised much. But unless what you're throwing out is 100% padding, there's always some signal that is being lost, to the detriment of the fidelity of the final encoding. Whether this is relevant in practice needs to be determined on a case-by-case basis.