Talk:Raw image format
|WikiProject History of photography|
|WikiProject Film||(Rated C-class)|
- 1 Software support
- 2 PRONUNCIATION
- 3 Merged
- 4 Marketing aspects
- 5 Conversion
- 6 (However, overexposed areas are just as white with 12 bits as with 8, so using raw is not a substitute for correct exposure.)
- 7 Accuracy
- 8 List of cameras supporting a RAW format
- 9 Questionable
- 10 Capitalisation consistency
- 11 Raw is not a format
- 12 Images
- 13 Requested move
- 14 Apple Aperture raw processing limited to selected cameras.
- 15 Proposed merge from digital negative
- 16 Inaccurate/Misleading Information
- 17 Innov8or's large edit
- 18 TIFF is NOT a RAW file... or is it?
- 19 Raw images necessarily come from a camera or scanner?
- 20 Rewrite
- 21 Naming conventions for image file formats
- 22 Emerald Explanation
- 23 Raw image files - digital negatives metaphor in the intro
- 24 Digital development
- 25 Standardization section
- 26 TIFF misconceptions
- 27 the raw that isn't medium-rare
- 28 Bayer filter diagram
- 29 Mis-use of the term "raw image file"
- 30 Sensor image data
- 31 What RAW formats are uncompressed?
- 32 Standardize RAW vs raw
- 33 this doesn't make much sense
- 34 Edit request
- About The GIMP, the article says: "The latest version of GIMP, a free open source photo editing package, imports many raw formats. Older version have a plug-in which allows it to read and convert raw files." What version does this refer to? Please ammend. —Preceding unsigned comment added by 188.8.131.52 (talk) 17:20, 27 January 2010 (UTC)
-I concur. My GIMP will not open Canon CR2 files (well, the Windows version won't). I realize most people install UFRaw, which works fine but RAW support is not native from what I can find. If this statement cannot be verified by anyone, it should be removed. 184.108.40.206 (talk) 05:57, 3 February 2011 (UTC)
I merged the "CCD-RAW" and "RAW image file" articles to create this one, and added some new text that corrects some errors in the previous versions (particularly in RAW image file). It can still use a lot of work; I don't know when I'll get a chance, so if someone else wants to contribute please do.
The color depth bullet is probably still confusing. Raw files have 12 bits per pixel, but only one channel (each pixel is either red, green, or blue depending on what color in the Bayer filter covered it. JPEG files have 8 bits per pixel for each channel (red, green, blue), so a total of 24 bits per pixel. But it's difficult to compare color depth between a 1 channel and a 3 channel image. I don't know if this needs to be explained here, in the color depth article, or not. If someone can explain this better, I'd appreciate it. If this is really confusing, let me know and I'll work on it.
A couple of new topics that might be useful:
- When NOT to use raw; a lot of people are very vocal about it being a waste of time: "shoot correctly and you don't need it"
- A list of common conversion programs (e.g., Capture-One, BreezeBrowser, Bibble, Photoshop CS and Elements 3)
- A list of file extensions for common raw formats (e.g., Canon uses CRW, Nikon uses NEF) (the German version has an incomplete list for starters)
- Some raw formats include an embedded JPEG, I think for quick extraction to evaluate overall quality before making the effort for a quality raw conversion; I don't know whether this is universal or why it is really used so didn't include it
- More than just a pointer to Adobe DNG, although this could wait a few years to see how well it is received
--Rick Sidwell 20:45, 10 Dec 2004 (UTC)
- "Raw files have 12 bits per pixel, but only one channel (each pixel is either red, green, or blue depending on what color in the Bayer filter covered it. JPEG files have 8 bits per pixel for each channel (red, green, blue), so a total of 24 bits per pixel."
- That is interesting I would like to see that in the article, about how each pixel is a certain color due to the physical sensor having R, G, and B sensors.
- I will try to add mosaicing to the article. However the quality of JPEG vrs Raw is simply untrue. JPEG is not RGB. Each RAW pixel contains 12 bits of brightness information. Whereas JPEG includes only 8 bits of brightness information. Color and saturation are (depending on the parameters) stored at considerably lower resolution. Therefore a RAW image will always have sharper brightness details than a jpeg even if they were both from a better external source. This is a crude simplification of JPEG btw. In reality it is more of a mosaic itself with colors and brightness gradients defined at intervals. --Darkfred Talk to me 21:48, 17 July 2006 (UTC)
While RAW support is a standard feature on dSLRs, it was also included in a lot of compact cameras several years ago, but few people used that because memory cards were expensive. Now memory cards are cheap,but it seams marketing has found RAW to be a "pro" feature and they use it to differentiate product categories. Example: The Nikon Coolpix P5100 and P5000 cameras are quite high quality products but they don't have RAW support while their predessor the Nikon Coolpix 5000 included it. —Preceding unsigned comment added by 220.127.116.11 (talk) 16:05, 14 February 2008 (UTC)
- I don't think the conversion would be reversable, and a certain amount of information would be lost.
- You can to a perfect bit-for-bit lossless conversion to Adobe DNG, which is an unusual type of TIFF. With PNG and normal TIFF, you only lose from round-off error and from the loss of little odds and ends like knowing the alignment of the pixels to the camera sensor. It's not like going to a GIF or a low-quality JPEG. --anonymous
- But the conversion is still not reversable from .DNG, simply because the digital development settings (contrast, color, curves) are not replicated 1:1 between adobe raw and the various manufacturers conversion utilities. There might be other information changes, I don't know if .dng supports the full range of bit depths that various manufacturers have. .DNG attempts to be a simple unified format whereas the manufacturers each have specific quirks in what data is saved and how it is stored. --Darkfred Talk to me 15:13, 13 April 2006 (UTC)
- Oh no. Optionally, Adobe DNG can cheat. It can store all the unrecognized and unconvertable parts of the original file as a great big arbitrary blob. When you convert back, the original can be reconstructed bit-for-bit. AlbertCahalan 04:49, 16 April 2006 (UTC)
(However, overexposed areas are just as white with 12 bits as with 8, so using raw is not a substitute for correct exposure.)
This is not entirely true. Most blown out areas are only blown out in one or two channels. Adobe's latest version of camera raw software can recover a brightness value from these channels, that is quite realistic, and mix this with the color values from nearby pixels to produce nearly perfect recovery of some highlights. (i have used it to recover entire faces correctly). --Darkfred Talk to me 11:50, 22 September 2005 (UTC)
I have tried to make the article more accurate by explaining the mosaicing process and changing the comparison with JPEG to relate to how JPEG is actually stored. (previous editor was confusing JPEG with uncompressed RGB, and confusing mosaiced 12bit RAW with 36bit RGB). My grammer is not the best, feel free to make it more readable. --Darkfred Talk to me 22:24, 17 July 2006 (UTC)
List of cameras supporting a RAW format
This section must be in it's own article, if it should exist at all. When complete, it will be too long for the RAW article. For example, all cameras listed on thedcraw-page should be included in this list. Berland 13:29, 18 February 2007 (UTC)
- How about convert to list of raw formats, with corresponding companies, instead (like the box at top but with more info maybe)? Dicklyon 15:16, 9 March 2007 (UTC)
- That is much more interesting than a long list of camera models Berland 16:21, 9 March 2007 (UTC)
I started the list of camera models with raw, and a similar section in TIFF. Uninteresting I agree, but I was looking for a camera with raw mode and couldn't find a comparison table anywhere, and ended up making a list myself. It's the sort of useful information that a continuously updated encyclopaedia excels at. So I think that this list belongs somewhere on Wikipedia, though not necessarily in the article on raw formats. Pol098 02:24, 10 March 2007 (UTC)
- Thanks for that, I'd never have created the list if I'd known that site. Though I still think the list is worth having, perhaps on its own page. Pol098 23:47, 10 March 2007 (UTC)
Are there any objections to moving it to its own page? Berland 10:15, 10 March 2007 (UTC)
- Noone seemed to oppose this, so I did the move, see List of cameras supporting a raw format. Berland 16:59, 17 March 2007 (UTC)
Would there be place somewhere on Wikipedia that lists which cameras are supported by a given software? I am asking because I created one for Apple and Adobe, including the date when they received support and software version which delivered the support.
However, RAW permits much greater control than JPEG for several reasons:
Finer control is easier for the settings when a mouse and keyboard are available to set them. For example, the white point can be set to any value, not just discrete values like "daylight" or "incandescent".\
The settings can be previewed and tweaked to obtain the best quality image or desired effect. (With in-camera processing, the values must be set before the exposure). This is especially pertinent to the white balance setting since color casts can be difficult to correct after the conversion to RGB is done.
- Both can be done on JPEG images using appropriate software. Similarly they can only be done using appropriate RAW software. I understand there are apparent quality differences between doing this on a 'altered' image and a 'unprocessed' image, but the article currently seems to suggest it isn't possible in JPEG. ny156uk 20:32, 2 April 2007 (UTC)
- Your point is correct. The important point in this context is only the final quality, which is limited by either 8-bit for JPEG or 12/14/16 bit for RAW format. --Berland 20:47, 2 April 2007 (UTC)
- What's not possible with a JPEG is any recovering of information in pixels that have already been clipped to the colorspace gamut. It's not because it's JPEG (same deal with TIFF), but because it has been rendered to a colorspace. With raw, there is no such clipping gamut, just sensor saturation limits. But you're right, the article does need work. Dicklyon 23:35, 2 April 2007 (UTC)
The article uses "raw", "Raw", and "RAW" inconsistently. Someone who knows more about what is acceptable should advise on which one to use throughout the article, and use just that one. 18.104.22.168 00:08, 6 May 2007 (UTC)
(Erk just not logged in)
- Per comment below, lower-case is more logical. Anyone object if I change it? Dicklyon 23:09, 15 May 2007 (UTC)
I don't call it RAW because—in the words of the article—I believe it is a single file type, but simply because it is a file type. The lower-case spelling is also logical. --Adoniscik (talk) 00:58, 22 February 2008 (UTC)
- Use of capital letters makes sense. RAW is an acronym for Read And Write. Sorry, no citation. — Preceding unsigned comment added by Charles McRobert (talk • contribs) 01:47, 21 March 2016 (UTC)
Raw is not a format
Raw is just a collective term for the different camera manufacturers properitary file formats for saving unprocessed images directly from the CCD. Therefore it should be written raw and not RAW --EivindF 14:51, 8 May 2007 (UTC)
- I agree, logically. But about half the books that talk about RAW use all caps, as if it was a file type. I think that's because conceptually it is a type of file, even though maybe different actual types and formats. Dicklyon 15:08, 8 May 2007 (UTC)
- It is a question of grammar, nothing more. Raw is not an acronym, and whether it is a format or not plays no role in how it should be written. It is a noun and an adjective, and should be written as such. A significant number of magazines and online articles use the capitalized spelling, "RAW", yet prevalence does not imply correctness. This is just reluctance on behalf of these authors to think about what they're writing and apply correct grammar to it. DrSlony (talk) 02:38, 23 June 2012 (UTC)
I suspect that these images could be used in this article, but I don't know enough about them to be sure, perhaps editors might find them useful?:
- Image:Minolta Dynax 7D RAW Camera White Balance.jpg
- Image:Minolta Dynax 7D RAW 6000K.jpg
- Image:Minolta Dynax 7D RAW 3500K.jpg
Cheers--DO11.10 22:37, 15 May 2007 (UTC)
- Someone already added a set like that in the color balance article, which seems more sensible, since they have more to do with white point and color balance than with raw format. Although, if he doesn't fix the license, those will disappear. Yours are a bit unclear, as the Exif says Auto White Balance on all of them. How were these images made? Dicklyon 23:03, 15 May 2007 (UTC)
It was requested that this article be renamed but there was no consensus for it be moved. But, since the split history had to be merged anyway, I have ended up moving the article to be at raw image format, if only because that did away with the need for moving this talk page. --Stemonitis 09:16, 6 June 2007 (UTC)
- Thanks; with only one weak oppose and one Microsoft supporter in opposition, the consensus seemed close enough. Thanks for fixing the previous improper move. Dicklyon 14:36, 6 June 2007 (UTC)
Apple Aperture raw processing limited to selected cameras.
"Finally, in October, Apple released Aperture, a photo post-production software package for professionals whose chief feature
is full support for raw files." Actually it only supports a few cameras' raw images as of 7/22/2007. See the post on the apple site below.
I was quite suprised to find my Panasonic DMC - FZ8 raw files imported with a blank "Unsupported Image Format" message.
LoghouseJD 19:04, 22 July 2007 (UTC)loghouseJD
Proposed merge from digital negative
Since the guy who tagged it didn't start the discussion, I will.
Support – the two articles seem to be on the same topic. Adobe's "Digital Negative Format" is a specific raw format, but that's not what the digital negative is about. Dicklyon 02:32, 15 August 2007 (UTC)
I'm the guy who tagged it. It seemed to me that it's really the same concept: "digital negative" is slightly more abstract, and this page is more concrete, but that's it: all discussion about why it's good to have a digital negative for an image, what you can do with it, who supports etc, that's one article. Stevage 07:20, 15 August 2007 (UTC)
Support - there is not enough common knowledge on the abstract "digital negative" to warrant its own article yet. --Berland 20:21, 8 October 2007 (UTC)
- I did a merge. Feel free to work it over. Dicklyon 06:19, 22 October 2007 (UTC)
Camera raw files have 12 or 14 bits of intensity information, not the gamma-compressed 8 bits typically stored in processed TIFF and JPEG files; since the data are not yet rendered and clipped to a color space gamut, more precision may be available in highlights, shadows, and saturated colors.
It should read:
Camera raw files have 12 or 14 bits of intensity information, not the gamma-compressed 8 bits typically stored in processed JPEG files; since the data are not yet rendered and clipped to a color space gamut, more precision may be available in highlights, shadows, and saturated colors.
- It's not really inaccurate, since the 8-bit processed images are indeed typically stored in TIFF files, and since TIFF files typically store 8-bit images. Yes they can also store 16-bit images, but that doesn't make it untrue or misleading. Dicklyon 06:06, 22 October 2007 (UTC)
Well a TIFF file can have 8 bit content, to say raw's benefit over tiff is that tiff can store only 8 bits per channel is misleading, as tiffs can store either 8 bit per channel OR 16 bit channel information. Thus, I would say remove TIFF from the discussion, because this section is really talking about RAW versus JPEG, JPEG can ONLY be 8 bits per channel.--Xenoptrix 06:14, 22 October 2007 (UTC)
- Yes, that would be misleading if one said that. However, it doesn't say that's a benefit over tiff, it says it's a benefit over 8-bit images. The rest of the statement "since the data are not yet rendered and clipped to a color space gamut, more precision may be available in highlights, shadows, and saturated colors" should probably be clarified as being an advantage over tiff, however. Work on that; taking TIFF out is going the wrong direction. Dicklyon 06:41, 22 October 2007 (UTC)
"it says it's a benefit over 8-bit images" however, TIFF is implicated as being an 8 bit per channel format. I think this comparison is rather lax, it needs a more rigorous comparison. Because 8/16 per channel of the TIFF or 8 per channel JPEG image is NOT the same 12/14 bit per channel of the raw image. Instead the TIFF/JPEG channels are reinterpretations of mosaic pattern. Upshot: the term bit-depth has been applied in two different contexts, but for each context, bit-depth means something different.--Xenoptrix 07:32, 22 October 2007 (UTC)
How do I send a message to you, Dicklyon? I am new to wiki editing, it seems like you only see my comments here after I've edited the wiki entry. --Xenoptrix 06:26, 22 October 2007 (UTC)
- All the pages I edit are on my watch list, so if you address me on a talk page I'll see it; or use my page User talk:dicklyon. Or use the email link on my user page to send me an email. Dicklyon 06:41, 22 October 2007 (UTC)
Innov8or's large edit
Innov8or (talk · contribs) recently checked in a very large edit. I'm highly suspicious of such large edits, but Google doesn't turn up any sources for copyright violation. Going through the material he changed, I notice he changed the release year of Apple iPhoto 5 from 2005 to 2006. A Google search turned up the Apple press release announcing iLife '05 (which included iPhoto 5). It was indeed released in 2005 - a year before LightZone, which Innov8or has been advertising in this and several other articles. Given his history (and obvious motivations) and the tone of the new material, I'm inclined to just revert it. However I'm wondering if any of it is actually useful and could be rescued with a lot of editing. --Imroy (talk) 10:35, 18 December 2007 (UTC)
- Yeah, I agree... questionable although no obvious copyvio. Beyond that, his material was unsourced. I think it was appropriate to rv. Parts of it might be useful if sourced. ǝɹʎℲxoɯ (contrib) 16:33, 18 December 2007 (UTC)
- I reverted it before I noticed the comments here. It's a big opinion essay mostly. Probably has some good points, but without a source to back them up, they seem to be more about his agenda as you note. Innov8or, feel free to contribute, but preferably in manageable chunks that make verifiable points with an encyclopedic style. Dicklyon (talk) 16:36, 18 December 2007 (UTC)
TIFF is NOT a RAW file... or is it?
The table "RAW image file" at the top of this article incorrectly lists TIFF (.tif) as a RAW file format for Kodak. Clearly, this standard exchange format is not a RAW file. However, the TIFF format is technically a general-purpose container format that could theoretically contain any arbitrary data (including RAW subpixel data) if a few engineers were sufficiently out of their freaking minds and applied for a private range of tag values for that purpose....
So the question is this: did Kodak really do something as bonkers as writing RAW subpixel data into a TIFF file, or did somebody just throw up a list of formats that Kodak cameras support and not check it carefully? If Kodak did do something so utterly bizarre, this should be clearly noted. If not, the mention of .tif should be removed.
Either way, the mere thought of embedding RAW subpixel sensor data in a TIFF container is going to give me nightmares tonight. If I wake up crying, I'm blaming all of you. :-D
P.S. You left out the Rollei .rdc format, the Sinar .sti format, and probably a bunch of others. See http://pa.photoshelter.com/help/tour/formats for a large list and search for "raw".
- Actually, most vendors have chosen to use TIFF as the file format for their camera raw data. TIFF (tagged image file format) provides a very flexible container. But these TIFF files should not be opened and displayed as if they contained a regular image. Dicklyon (talk) 23:12, 23 February 2008 (UTC)
Raw images necessarily come from a camera or scanner?
Is it necessarily true that a raw image must come from a camera or scanner? It is my opinion that a raw file is a raw file regardless of its source.
I believe that years ago (I think before scanners and digital cameras were common), various sorts of image files regarded as "raw" existed; e.g. a screenshot taken directly from the framebuffer would be regarded as raw. There are old programs such as rawtoppm (part of the netpbm software), which considers RGB data to be raw. (Confusingly, netpbm's ppm format exists in "raw" and "plain" varieties, which are different.)
Anyway, my point is that the term "raw" for image files has a long history and hasn't always referred exclusively to digital camera or scanner images. 22.214.171.124 (talk) 22:46, 23 February 2008 (UTC)
- There is a completely different use of the term raw applying to image data, meaning image bytes in a file without any or much header or structural info or metadata. That's a raw "format". This article is more about raw image data. They do get confused a lot, so maybe it's worth a clarifying explanation. Dicklyon (talk) 23:10, 23 February 2008 (UTC)
The Software Support section needs a complete rewrite:
1: It makes the issue look MUCH more complicated and scary than it is. Pretty much use any major photo editing software, and you are fine. The use of raw does not require the use of proprietary (for that camera model/manker) software to the degree this section suggests.
2: It has a "proprietary bad, open standards good" tone to it.
3: There doesn't seem to be any rhyme or reason as to the order and layout of the various software applications. Maybe it can be broken up in sections, such as major commercial photo editing software; photo viewing apps; support within OS GUI; niche photo editing software (such as GIMP); etc. —Preceding unsigned comment added by 126.96.36.199 (talk) 20:05, 5 August 2008 (UTC)
Naming conventions for image file formats
Please see the discussion at Talk:Image file formats#Naming_conventions_for_image_file_formats on naming conventions for articles on image file formats. Dcoetzee 00:47, 25 October 2008 (UTC)
Sorry Dicklyon. I think, and it seems, more appropriate my contribution on emerald explanation than the previous (cyan), because this two colours are different and clearly defined in the common use of the words. I suppose that in understanding of this differences between colours, is more useful to refer to specifics examples of colors of objects in normal condition of light (color temperature of the light near 5,000 K). No matter if in colorimetry (as a mathematical point of view), the two colours are very similar, our ordinary visual experience make us able to recognize and distinguish the two colors. (Zeus57) 16:11, 26 November 2008 (UTC)
- Thanks for linking emerald. I've also added sources that clarify that it's a blue-green or cyan sort of color; that is, on the blue side of green. If you can find further sourced info describing the color that Sony used, by all means do add it. Dicklyon (talk) 16:56, 26 November 2008 (UTC)
Raw image files - digital negatives metaphor in the intro
two paragraphs in the intro propose a metaphor relating raw files to film negs. but negs are open standards, are very broadly supported, and are suitable for long term archiving. raw files use a plethora of closed, often secret, proprietary file encodings, not widely interoperable, and concerns about potential bit-rot are widely discussed.
adobe's attempt to rationalize the raw mess with their open standard Digital Negative (file format) confuses the metaphor further.
add to this the fact that many (and ever more) younger people will have never used negatives and for them the metaphor wont help them.
to clarify the concept of a raw file, i think the intro would do better to contrast it with the other files that cameras and scanners typically produce, such as jpeg, pdf and what have you.
- Agreed. There are too many weak analogies to film processing, and they don't fit. Another is "developing". Digital images can be processed in many steps. It's also important to understand that JPEGs cannot be displayed directly either. You need software to convert them into screen images or paper prints. In that respect, the only difference between JPEG and raw formats is that JPEG converters are more widespread. But that's because it's a standard, not because it's easier to display. I suggest updating the page to explain this. Groogle (talk) 22:05, 27 February 2010 (UTC)
I've removed the statement that digital development is formally known as demosaicing, since demosaicing is only part of the digital development process
I edited this section to contain OpenEXR, the much overlooked and imho best open format to store Raw data in, that is currently available.
The digital effects industry has moved completely to this format for most digital intermediate work over the last few years. Image editing software like Apple' Shake, Foundry's Nuke, or Autodesk's Toxic support OpenEXR perfectly. The lack of support for OpenEXR in most (any) raw processing software used by digital photographers, on the hand, still eludes me but I presume that Adobe brings a lot of momentum in pushing a format (DNG) that they more or less control.
- Possibly one reason is that the support of metadata does not seem to be standardised in OpenEXR.
- Martin.Budden (talk) 09:55, 11 January 2009 (UTC)
- I've looked into this a bit further and http://www.openexr.com/ReadingAndWritingImageFiles.pdf states
- "For the current list of standard attributes, see the header file ImfStandardAttributes.h" Looking at http://openexr.sourcearchive.com/documentation/1.6.1/ImfStandardAttributes_8h-source.html it seems that a fairly small set of metadata is supported.
- Martin.Budden (talk) 16:35, 11 January 2009 (UTC)
I also miss OpenRAW in this section. But having doubts about the need for either DNG or OpenRAW, given the existence and maturity of OpenEXR, I don't feel like fixing this. ;-)
Finally, the article mentions that DNG "has been received enthusiastically by open-source developers". Firstly, the reference cited only contains a statement from a single developer, so the plural is dubious.
- I agree, this certainly does not seem an unbiased statement.
- Martin.Budden (talk) 09:55, 11 January 2009 (UTC)
Furthermore, while many OSS programs support DNG now, it is unclear at best if this is so because they have to or because they choose to.
I'd vote for changing this sentence or removing the resp. part of the sentence entirely. It smells like it was written by some marketing guy on Adobe's payroll. MoritzMoeller (talk) 19:28, 10 January 2009 (UTC)
- I agree that the tone of this sentence is out of place here. However, Dave Coffin is a well-known independent who, in some ways, competes with Adobe, and who supplies software to Adobe's competitors. His statement was about a "free to use" file format that happens to belong to Adobe, (exactly the same is true of TIFF!), not about an Adobe commercial product. (For interest, I too have been falsely accused of being on Adobe's payroll because of my statements about DNG. But the fact is that, in the world of raw image formats, DNG has several specific and verifiable merits that distinguish it from other formats.) Barry Pearson 09:11, 17 September 2009 (UTC)
- I've changed "received enthusiastically" to "exploited" to make the tone more neutral. In fact, some developers have been enthusiastic, but that would be better stated (and verified) in the "Reception" section in the DNG page, rather than the "Standardization" section here. Perhaps this whole paragraph should be removed? Barry Pearson 07:32, 24 September 2009 (UTC)
Any discussion of standarization must include the fact that there has been an ISO standard raw image format, TIFF/EP, since 2001. Especially since TIFF/EP has been under revision since 2006, and hence it is standardization currently in progress. (There is a timeline at the TIFF/EP page). It is well-established that Adobe have offered DNG to ISO for this purpose. A likely consequence of what is publicly known is that, sooner or later, version 2 of TIFF/EP will be published with "interoperability profile 2" being a raw image format based largely or entirely on DNG and using the extension ".DNG". The logic for this is impeccable - ISO are revising and extending an existing standard, and drawing upon a format that is already an extension of that standard and being used in the marketplace makes it a lot easier to publish a credible revision. ISO will not waste effort, and risk confusion, pursuing other options in parallel. TC42 WG18 is recognised to be the ISO group charged with such electronic photography standards, and they are busy with TIFF/EP and others. (I referenced I3A (International Imaging Industry Association) - they are the secretariat for the ISO Technical Committee 42 (ISO/TC42) (scroll down), responsible for standards for electronic photography). Barry Pearson 12:29, 16 September 2009 (UTC)
- I've tweaked the parts of "Drawbacks" that didn't recognise that there actually is a standard raw image format. Barry Pearson 07:32, 24 September 2009 (UTC)
Other standards bodies may adopt other specifications, but standards bodies have a tendency to accept what other bodies have standardized, unless there is a good reason not to, so that they can concentrate on their own specialist fields. I am not aware of any other standards body that feels that the raw image format of digital still cameras is within its scope and that it needs to develop such a standard independently of ISO. Barry Pearson 12:29, 16 September 2009 (UTC)
I question the inclusion in this section of OpenEXR, SMPTE DPX, and HD Photo / JPEG XR. In particular, while researching for the publication of my 6 web pages on HD Photo / JPEG XR over more than two and a half years, I have not seen an "official" suggestion that it is intended to become a raw image format with the ability to hold raw image data. (That is, to hold separate data from the individual sites of a sensor with a color filter array). Instead, it is intended to be (inter alia) a high-quality alternative to shooting raw, offering better quality and flexibility than normal JPEG. (JPEG XR has now been ratified as International Standard ISO/IEC 29199-2 and also ITU-T Recommendation T.832, and that version is certainly not capable of supporting such raw image data). The OpenEXR and SPX pages in Wikipedia give no hint that they are to be (or could be) enhanced to be raw image formats, and it is strange that this current page contains more speculation about them than their own pages. Barry Pearson 12:29, 16 September 2009 (UTC)
- I've now removed those other file formats from this section. The HD Photo sentence was inaccurate and out-of-date: it has now become a standard, and doesn't support raw images. There is no evidence that I can find anywhere that OpenEXR and DPX could be turned into raw image formats, nor that anyone intends to, nor that anyone intends to submit the results for standardization, nor that any standards body is interested in adopting them for this purpose. I believe any such activity should be verified on their own pages before being used here. Barry Pearson 07:32, 24 September 2009 (UTC)
I have removed the term "patent encumbered" from the text about DNG because there is no evidence for it. In fact, in September 2009 Adobe stated (in a launch of material for CinemaDNG) "There are no known intellectual property encumbrances or license requirements for CinemaDNG or its underlying formats DNG, TIFF, XMP, or MXF". The "Digital Negative (DNG) Specification Patent License" that was being cited as evidence for patents on DNG is not such evidence (and is more than 4 years older than the recent Adobe statement). That License does not state that there are patents on DNG, and certainly doesn't identify any. In effect, it says "whether or not there are any patents is irrelevant because you have the right to exploit DNG anyway". In other words, it eliminates the possibility of any such "encumbrance" upon the exploiter, and provides reassurance. Barry Pearson 08:45, 17 September 2009 (UTC)
I have been researching and debating DNG for nearly 5 years, and I have never found or been informed of a patent. I have searched the US Patent and Trademark Office site for any such patent, and I haven't found one. It is hard to prove a negative, but given that the License is not evidence for patents, and in view of Adobe's recent statement, I believe the onus is on anyone claiming that DNG is "patent encumbered" to identify at least one patent that encumbers DNG. Barry Pearson 08:45, 17 September 2009 (UTC)
I have brought the text about support of DNG by camera makers up to date, but also removed identification of specific cameras. The page on DNG has such a list, and I have added a reference to my own page that I attempt to keep up to date and comprehensive. This list changes frequently (I have added a few cameras to it during September 2009) and attempting also to keep 2 separate pages in Wikipedia up to date appears to be a waste of effort (and likely to fail). Barry Pearson 08:45, 17 September 2009 (UTC)
I noticed quite a few debates about TIFF on this discussion page. The TIFF article in Wikipedia is unfortunately poorly written so I can't point to this one as a source of facts. But: TIFF is a container. Many TIFF flavors exist. Confusion about bit depth: In print & web, people often talk about 24 bit TIFF, meaning a 3*8BIT RGB TIFF. Similarly people mean "indexed" color when they talk about 8 bit images. This is per-image bit depth. In other fields, people talk about per channel bit depths. E.g. 8 or 16 bits. Often overseen/ignored by the digital photographers, but TIFF can store floating point data in 32bits per channel. Channels can be interpreted in different ways. TIFF tags serve to identify what they mean. Common formats for floating point (raw) data in visual effects, digital cinematography and scientific imaging for TIFF are:
- log Luv
Of course, there's also plain RGB data with 32 bits per channel. Most of these are also identified correctly & read by Photoshop.
Finally, 32 bit/channel floating point RGB TIFF with or w/o lossless compression (e.g. LZW or Adobe Deflate, aka ZIP) is a valid raw data container. So a generic statement like "TIFF is a raw format" is true in consideration of this fact.
The float data is linear, no information is lost unless the sensor the data came from had more than 32 bits/channel precision (not the case for any cameras used by most mortals for another few years, 14-16 bit seems to be max). MoritzMoeller (talk)
- So a generic statement like "TIFF is a raw format" is true in consideration of this fact. That does not follow. It might make sense to say that TIFF can be used as a raw image format. Indeed many raw file formats use TIFF as the container, including Adobe's DNG. That doesn't make TIFF a raw format. Dicklyon (talk) 08:33, 16 January 2009 (UTC)
the raw that isn't medium-rare
I came to this article looking for information about the format of .raw files, where there isn't any metadata at all, not even dimensions or color depth, just bits (or bytes if you don't look too close :) ) and to be open requires you to specify on the program the dimension, color depth and a few other parameters if the color depth is bigger than 1 bit, where can I find more information about it? --TiagoTiago (talk) 22:24, 14 May 2009 (UTC)
- In the documentation of the hardware that produced that raw sensor dump.DrSlony (talk) 03:22, 23 June 2012 (UTC)
Bayer filter diagram
I think this page would benefit from a diagram of a typical bayer filter. It's a pretty significant difference from most image formats. None of the images currently on bayer filter are quite what I'm looking for. —Darxus (talk) 15:40, 16 September 2009 (UTC)
Mis-use of the term "raw image file"
Raw image file is actually an uncompressed image without any header (the image inside may be coded with RGB/YUV or other color spaces). This article is actually talking about CCD/CMOS data. The term "raw image file" is actually a mis-use here.
Opening a raw image file requires user explicitly specifying the width and height of the raw image. This is because raw image file does not have header data. CCD/CMOS data files however, contains even more information (exposure settings, shutter, etc.) in the header file than some uncompressed file format like BMP. Therefore, they are well-formatted and not raw image files at all.
- That type of "raw" image file is not what this article is about. Not clear what you mean by "mis-use". Dicklyon (talk) 03:48, 11 February 2011 (UTC)
Sensor image data
In the section "Sensor image data", third paragraph, the second sentence has seven commas and a semi-colon, making it rather imcomprehensible.
What RAW formats are uncompressed?
Article states: "JPEG images are typically saved using a lossy compression format (though a lossless JPEG compression is now available). Raw formats are typically either uncompressed or use lossless compression, so the maximum amount of image detail is always kept within the raw file."
- I'm not aware of any actual uncompressed RAW formats, but I'm sure there must be one or two floating about. However, I doubt very much that they're typical in any sense. I thought I'd be bold and change it. — Preceding unsigned comment added by 188.8.131.52 (talk) 14:04, 20 April 2012 (UTC)
- I wouldn't say 'typically' since this implies a statistic which I'm sure no-one here has carried out, but a raw image is just a dump of a sensor's data, and it's up to the designer whether he wants to compress that or not. DNGs can be uncompressed. DrSlony (talk) 03:25, 23 June 2012 (UTC)
Standardize RAW vs raw
This article heavily favors the use of "raw" over "RAW", which I feel is the correct way anyway. I would suggest that, aside from external references, all instanced of RAW are switched to raw, and going forward that's all that's used.
- Yes, of courese. I have generally edited in that direction, but may not have kept up with all... Dicklyon (talk) 16:44, 29 May 2012 (UTC)
this doesn't make much sense
"camera raw image file contains minimally processed data from the image sensor of either a digital camera(...) Raw files are so named because they are not yet processed" - so... they are processed or they aren't? Introduction contradicts itself. SkywalkerPL (talk) 13:01, 8 July 2012 (UTC)
- I think the problem is really that the lead section is so poorly written that it's like getting repeatedly bludgeoned by dispicable laziness until one is dumbfounded, —until what might normally make sense does not. I think if you were not forced into a defensive position by the terrible writing (such as inappropriate argot, jargon, and excessive lazy-linking,) you would have breezed by that inconsistency.
—My guess? minimally processed = unprocessed.
But that will do you no good, will it? If writing quality is judged according to effectiveness of communication, (always the primal, basic criterion) then this lead section loses. It's embarrassingly bad. Curiously, the next few sections, —where these weaknesses are normally better tolerated,— do a much better job! More specifically, see Wikipedia:Manual of Style (lead section). Another hint: by definition it is utterly impossible for just one to communicate. Final clue; google: digital photography raw.
--184.108.40.206 (talk) 00:51, 13 March 2014 (UTC)Doug Bashford
This silly article claims that negatives are "not directly usable as an image". Really? I guess all of the negatives available for sale, as art, and all of the movies using negatives as part of the movie exist in some other Universe? I'd suggest the editors of this piece actually think about what they are writing and not expand analogies into the ridiculous. ... Oh, I found another gross blunder: it seems that Android 5.0 - according to this article - allows the smartphone user to take RAW images...how does a camera "take" a file format? It should be obvious that any device "takes" sensor dependent data - the only question is how are those (voltage? (for CCDs)) measurements encoded (into a file) for storage? (with possibly several stages of processing (intermediate representations of the raw measurements) prior to storage in a datafile, of course.)220.127.116.11 (talk) 21:35, 21 October 2015 (UTC)