Could you actually see photos made from RAW files?
anir...@gmail.com
However, I still have difficulties dealing with the concept of RAW
files. Someone suggested that RAW files are like negatives, while-as
JPEG files are like prints.
My question is whether we can physically see a RAW file... I mean
without placing it in the mercy of a software to open it as a JPEG
file (and in the mean time, the software is doing the processing and
converting it into JPEG using their own algorithm to produce what they
consider to be the best JPEG. I agree that perhaps people should
create both RAW and JPEG files when they take pictures.
The next question is whether commercial photo processing softwares
(Photoshop, Paintshop, Aperture, etc) treating RAW files produced from
different brand cameras differently, as I noticed that the extension
file name for RAW files differ from cameras to cameras. Can the
special software made by the camera's manufacturer (which sometimes
comes with the camera that you purchase) do a better job than the
commercially photo processing softwares?
I recall that someone mentioned that the camera's processing engine is
not as versatile as a computer's photo processing software, as well as
the time to produce the JPEG file in the camera is relatively short.
Therefore, built-in camera processing engine cannot make a better job
than a real photo processing software. As processing speed is getting
faster and faster, could a camera sometime in the future produces JPEG
photos which are as good as or better than the commercial photo
softwares?
Thanks for the discussions
nospam
<8eff0e4e-0aad-4415...@j12g2000vbl.googlegroups.com>,
<anir...@gmail.com> wrote:
> I am sorry if this topic may have been discussed too many times.
> However, I still have difficulties dealing with the concept of RAW
> files. Someone suggested that RAW files are like negatives, while-as
> JPEG files are like prints.
conceptually yes.
> My question is whether we can physically see a RAW file... I mean
> without placing it in the mercy of a software to open it as a JPEG
> file (and in the mean time, the software is doing the processing and
> converting it into JPEG using their own algorithm to produce what they
> consider to be the best JPEG. I agree that perhaps people should
> create both RAW and JPEG files when they take pictures.
software has to process the jpeg too. the difference is that raw is a
dump of the sensor data and jpeg is processed and lossy compressed. if
you want to adjust the image, it's *much* better to work with the raw
rather than a jpeg that's already lost some information.
> The next question is whether commercial photo processing softwares
> (Photoshop, Paintshop, Aperture, etc) treating RAW files produced from
> different brand cameras differently, as I noticed that the extension
> file name for RAW files differ from cameras to cameras. Can the
> special software made by the camera's manufacturer (which sometimes
> comes with the camera that you purchase) do a better job than the
> commercially photo processing softwares?
different raw converters produce different results. which one is best
is *very* subjective. the software that comes with the camera often
does produce a better result because the camera companies know exactly
what the sensor can do, whereas third parties have to figure out some
of it. whether you'll notice a difference and which one you prefer is
another story. adobe now has profiles that match the look of the
camera maker's software.
> I recall that someone mentioned that the camera's processing engine is
> not as versatile as a computer's photo processing software, as well as
> the time to produce the JPEG file in the camera is relatively short.
> Therefore, built-in camera processing engine cannot make a better job
> than a real photo processing software. As processing speed is getting
> faster and faster, could a camera sometime in the future produces JPEG
> photos which are as good as or better than the commercial photo
> softwares?
given the same parameters, you'll get essentially the same jpeg from
either the camera or the computer. the difference is you aren't stuck
with those settings if you shoot raw. you can decide on different
settings after you shoot, such as white balance. this is really
helpful if you accidentally forget to switch from sunny to indoor, for
example, or if the auto white balance doesn't quite get it right.
Trev
> I am sorry if this topic may have been discussed too many times.
> However, I still have difficulties dealing with the concept of RAW
> files. Someone suggested that RAW files are like negatives, while-as
> JPEG files are like prints.
> My question is whether we can physically see a RAW file... I mean
> without placing it in the mercy of a software to open it as a JPEG
> file (and in the mean time, the software is doing the processing and
> converting it into JPEG using their own algorithm to produce what they
> consider to be the best JPEG. I agree that perhaps people should
> create both RAW and JPEG files when they take picture
Any converter soft ware creates a image for display on the monitor based on
the data from the RAW file. Its Just a raster image and until it is saved
as a jpeg or tiff or anything else That's is all it is. The deference is if
you save your photos in camera as jpeg it does the conversion once and
that's it. Where as the raw can be adjusted by the user in the software to
look as the user want not as is preset for all images in the camera. If you
have Vivid setting turned on by mistake or wrong WB you have it for life.
>
> The next question is whether commercial photo processing softwares
> (Photoshop, Paintshop, Aperture, etc) treating RAW files produced from
> different brand cameras differently, as I noticed that the extension
> file name for RAW files differ from cameras to cameras. Can the
> special software made by the camera's manufacturer (which sometimes
> comes with the camera that you purchase) do a better job than the
> commercially photo processing softwares?.
Well as a paintshop pro fan I can tell you it does not give much control
over the conversion. The manufactures software may well give better control
(in most cases it does). Third party converts rawtherapee.or such is better
Lightroom Is tops especially if you have more then one brand of camera
>
> I recall that someone mentioned that the camera's processing engine is
> not as versatile as a computer's photo processing software, as well as
> the time to produce the JPEG file in the camera is relatively short.
> Therefore, built-in camera processing engine cannot make a better job
> than a real photo processing software. As processing speed is getting
> faster and faster, could a camera sometime in the future produces JPEG
> photos which are as good as or better than the commercial photo
> softwares?
It will always have the same conversion for each image right or wrong.
Software on the computer allows you to fine tune the raw data to produce
what you want prior to the conversion but without changing the original raw
data. The adjustments are saved along with the image to recreate the same
output if you want at a later date or you could alter the setting to produce
a different output
>
> Thanks for the discussions
Savageduck
I will try to keep this simple, others can expand on the esoteric.
Regardless of the terminology "Digital Negative" a RAW file is just the
"RAW" unprocessed data as recorded via the sensor. As such it if the
"purest" set of digital data available to decode the image. JPG files
are compressed and are "lossy" that is they do not retain all the
original information contained in the RAW file.
TIFs or PSDs are lossless files, but are not RAW files.
The only physical way to "view" this data would be as a print out of
the code which is the RAW file.
Yes different manufacturers use different RAW encoding and as cameras
and sensors develop you will find that there is no common RAW file in
each manufacturer's family of cameras. For example NEF files are
different for each of their cameras, They might as well name them
NEF-101, NEF-102, etc.
So to answer, you need software to read or interpret RAW files. There
are quite a few RAW decoders, I will only speak of Adobe Camera Raw
(ACR).
Opening the RAW file in ACR allows you to make flexible,
non-destructive adjustments, such as white balance, apply adjustment
curves or levels, and many others.
Many of these adjustments can be set in camera when shooting JPG,
however that is what you will have to live with. RAW allows you the
flexibility to make these adjustments nondestructively and retain the
original data straight from the sensor, and you need software to
achieve that.
Maybe one of these day we will be able to make those adjustments in the
camera, and to some degree we can, note things such as Nikon's
D-Lighting. Remember you are still going to be limited by working with
that tiny LCD display on the camera.
--
Regards,
Savageduck
Steven Green
programmer but I will give my 2 cents on this.
anir...@gmail.com wrote:
> I am sorry if this topic may have been discussed too many times.
> However, I still have difficulties dealing with the concept of RAW
> files. Someone suggested that RAW files are like negatives, while-as
> JPEG files are like prints.
It is my understanding that just to view camera raw data conversions
need to be done to the image to make it viewable. For example in the
camera you select the white balance. The image is processed according to
the white balance settings and that is what you see on the screen at the
end and in the generated jpeg.
> My question is whether we can physically see a RAW file... I mean
> without placing it in the mercy of a software to open it as a JPEG
> file (and in the mean time, the software is doing the processing and
> converting it into JPEG using their own algorithm to produce what they
> consider to be the best JPEG. I agree that perhaps people should
> create both RAW and JPEG files when they take pictures.
I don't know specifically what the values stored in the file represent,
be they voltages or light values, I will assume for simplicity that the
internal computer converts the sensors voltage into a bunch of pixels
and stores these in the raw as a bitmap. If that is the case you could
theoretically display the bitmap without any additional conversions but
it may not display well, I don't know enough about the file itself to
give a good answer here.
>
> The next question is whether commercial photo processing softwares
> (Photoshop, Paintshop, Aperture, etc) treating RAW files produced from
> different brand cameras differently, as I noticed that the extension
> file name for RAW files differ from cameras to cameras. Can the
> special software made by the camera's manufacturer (which sometimes
> comes with the camera that you purchase) do a better job than the
> commercially photo processing softwares?
In theory the camera could produce the same image you could produce in
photoshop processing-wise. Where the real difference, IMO rests, is with
the ability to change the settings to adjust the image after the fact to
what you like. The combination of the screen size and input mechanisms
for these software make the computer more effective.
My guess would be that the files store the data differently, but are
loaded into a common form and then used by the package. I would be very
surprised if after that point anything was different. It is possible
that the loader is required to perform some kind of conversion which
could in theory be done differently and maybe alter the image. Never
written a RAW file converter so again not sure what the technical
nitty-gritty is there.
>
> I recall that someone mentioned that the camera's processing engine is
> not as versatile as a computer's photo processing software, as well as
> the time to produce the JPEG file in the camera is relatively short.
> Therefore, built-in camera processing engine cannot make a better job
> than a real photo processing software. As processing speed is getting
> faster and faster, could a camera sometime in the future produces JPEG
> photos which are as good as or better than the commercial photo
> softwares?
Again I think there is no reason the JPEGs couldn't be identical if it
fit the camera's algorithms. To me the advantage with RAW over JPEGs is
that if you need to fix a jpeg you are also undoing what the camera did.
To fix a raw you select the options you want applied, in lightroom, I
start with a blank slate and (assuming I don't like the settings I had
at the time of exposure I just change them. I also keep raw to just make
sure that my images are not lossy, jpegs can use lossy compression when
being generated.
>
> Thanks for the discussions
"mcdonaldREMOVE TO...@scs.uiuc.edu
> I am sorry if this topic may have been discussed too many times.
> However, I still have difficulties dealing with the concept of RAW
> files. Someone suggested that RAW files are like negatives, while-as
> JPEG files are like prints.
> My question is whether we can physically see a RAW file... I mean
> without placing it in the mercy of a software to open it as a JPEG
> file (and in the mean time, the software is doing the processing and
> converting it into JPEG using their own algorithm to produce what they
> consider to be the best JPEG. I agree that perhaps people should
> create both RAW and JPEG files when they take pictures.
>
The answer is, at least for Canon, yes. There is public
domain software available that will convert the data, which is
intensity data at each pixel, into a pixel-for-pixel file, that is,
8 or 12 or 14 bits per pixel. This is not full color, it
is filtered by the Bayer filter.
You can then take that file and make a 24 bit file from it, by
moving red pixel values to the red byte, blue ones to the
blue byte, and green ones to the green byte, leaving the other
two bytes of each 24 bit number zero. This can then
be displayed on you computer. To get the color right you need to scale the
R, G, and B numbers correctly. It will display as
a color image, albeit rather dark since each pixel will
be mostly black.
I've done it, it works.
Doug McDonald
Floyd L. Davidson
>The answer is, at least for Canon, yes. There is public
>domain software available that will convert the data, which is
>intensity data at each pixel, into a pixel-for-pixel file, that is,
>8 or 12 or 14 bits per pixel. This is not full color, it
>is filtered by the Bayer filter.
>
>You can then take that file and make a 24 bit file from it, by
>moving red pixel values to the red byte, blue ones to the
>blue byte, and green ones to the green byte, leaving the other
>two bytes of each 24 bit number zero. This can then
>be displayed on you computer. To get the color right you need to scale the
>R, G, and B numbers correctly. It will display as
>a color image, albeit rather dark since each pixel will
>be mostly black.
>
>I've done it, it works.
>
>Doug McDonald
Most of the responses to the OP's questions are more or
less correct. This one is different, as virtually nothing
said above is correct. (Not even the comment about
software for Canon, as no it is not Public Domain at all.)
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com
Floyd L. Davidson
>I am sorry if this topic may have been discussed too many times.
>However, I still have difficulties dealing with the concept of RAW
>files. Someone suggested that RAW files are like negatives, while-as
>JPEG files are like prints.
Better analogies might make things clearer. You can buy
a house pre-built... that's like JPEG or a TIFF image.
Note that it not totally static, in that you can change
it with a coat of paint, you can add a window or a room,
etc etc. But basically all of those things are
additions (edits) to the original house (image).
You can also take a set of plans to the lumber yard and
have everything needed to make a house delivered to your
lot. It's boxes of nails, stacks of lumber and stacks
of paint and of this and stacks of that. You can follow
the original set of plans and make the house that was in
your mind when you looked at the plans, but you can also
use this same pile of parts to build an entirely
different house too. That's what a camera raw file (the
so called RAW format) is... a pile of parts that you
can build an image from, and while the photographer may
have had one specific image in mind when that pile of
data was saved, it can be restructured to make a lot of
different images too.
A JPEG or TIFF file contains an image. The RAW file
contains data to make an image.
For example, each "sensal" location on the sensor does
*not* translate to a single pixel in the resulting
image. Instead the data from at least 9 different
sensors locations is used to determine the Red, Green,
and Blue values for a single pixel.
The process where all of that data is interpolated is
called "raw conversion", and is much the same as
converting a pile of nails and boards into a house.
>My question is whether we can physically see a RAW file... I mean
There is no house yet, so you can't walk up and knock on
the door or go inside!
The data has to be converted to an image before you can
"physically see" it.
>without placing it in the mercy of a software to open it as a JPEG
>file (and in the mean time, the software is doing the processing and
>converting it into JPEG using their own algorithm to produce what they
>consider to be the best JPEG. I agree that perhaps people should
>create both RAW and JPEG files when they take pictures.
In fact almost all RAW file formats also include a JPEG
image generated by the camera (sort of a "model" of the
house). That can be a blessing (its quick to look at)
or a curse (it isn't necessarily a model of the house
you'll build).
>The next question is whether commercial photo processing softwares
>(Photoshop, Paintshop, Aperture, etc) treating RAW files produced from
>different brand cameras differently, as I noticed that the extension
>file name for RAW files differ from cameras to cameras. Can the
>special software made by the camera's manufacturer (which sometimes
>comes with the camera that you purchase) do a better job than the
>commercially photo processing softwares?
Generally speaking, there isn't really much difference.
But specifically, if you are extremely critical you
might be able to see differences. But the biggest
problem is that it requires a good bit of skill to
adjust different software to produce exactly the same
final image, and many people judge the "default"
results. Each software package might, of course, have
vastly different defaults...
But in fact, for most images, any of the large number of
raw converters can be used to produce the exact same
image from the original raw data.
>I recall that someone mentioned that the camera's processing engine is
>not as versatile as a computer's photo processing software, as well as
>the time to produce the JPEG file in the camera is relatively short.
Your PC has massively more compute power than the CPU in
the camera. Plus the camera has relatively course
granularity in making adjustments compared to what is
available with most computer programs. For example the
camera may give you a possibility of 10 values for
contrast adjustment, while a computer program may give
you 200.
The most obvious problem though is that you have to set
the camera *before* you have the data, and then you
can't change it. With post processing you get to see
what all of the possible images might be, not just one.
Post process is generally more productive than preprocessing.
>Therefore, built-in camera processing engine cannot make a better job
>than a real photo processing software. As processing speed is getting
>faster and faster, could a camera sometime in the future produces JPEG
>photos which are as good as or better than the commercial photo
>softwares?
Sure... but also consider that while you are shooting
you'd have to take the same amount of time to make those
adjustments, except it would be between shots. Usually
it's just much easier to shoot RAW and get on with more
exposures while using the camera, and then later spend
the time necessary for adjustment of each image.
Again, it's post vs pre.
Doug McDonald
Of course it is correct. Try it yourself. In response to your
troll, I will post on my web site tomorrow an example.
There **is** public domain software for Canon dSLRs, in DCRAW.exe.
You can get source code and look at it for yourself.
You need to tell dcraw to make absolutely plain
(-d or -D, I forget which) TIFFS (-T) and, if cyou so desire,
even gamma = 1.0.
I did it this afternoon. You can see the difference colored
pixels (different colors in the Bayer filter) in the
monochrome (grayscale) TIFF file.
And in the past I actually HAVE done the display that way, using
software I wrote myself. (Convert TIFF to plain genuine "raw"
bitmap using ImageMagick, then write a program to convert that
to 24 bit color as I described above.)
Could you exmplain how you could be so wrong?
Caveat: the dcraw code is dense. I have no 100% veridird what it does
by looking at the code. Don't attack me on this point
unless you have successfully understood the dcraw code which is
executed using -D or -d.
Doug McDonald
anir...@gmail.com
also like the analogy of building a house vs. renovate the house.
Perhaps in the future I will try to keep both RAW and JPEG files,
particularly when taking photos for important events.
I do, however, wonder that by working on raw format, one will end up
spending much more time post processing after the photos are taken.
This sometimes I do not have the luxury to do it. Therefore, I also
look around with interest on what camera is doing better than the
others (in terms of generating JPEG photos), or at least the
processing that this particular camera is suit to your likings in
colour, contrast, tones, etc.
I just have one question - if you take a photo which was out of focus,
could you actually make it in focus when you have the raw files?
One more time, I thank you very much to all responders for the very
useful discussion on this topic!
Regards
Steven Green
> You can get source code and look at it for yourself.
>
>
> Caveat: the dcraw code is dense. I have no 100% veridird what it does
> by looking at the code. Don't attack me on this point
> unless you have successfully understood the dcraw code which is
> executed using -D or -d.
I also downloaded the dcraw software a few months ago and looked it over
briefly, couldn't make sense of the code in short order so I have up on
it. It was just a curiosity to me so it didn't matter much. I hate how
some code can be so hard to read. Some programmers truly have a gift
there :) And those that can read it are somewhat blessed.
Steven Green
sensor is. What you see in a jpeg is essentially the same you will see
in the raw. You have no more control of focus in a raw than in a jpeg
Savageduck
> Thanks for the overwhelming replies. I appreciate this very much. I
> also like the analogy of building a house vs. renovate the house.
> Perhaps in the future I will try to keep both RAW and JPEG files,
> particularly when taking photos for important events.
Always save the RAW files they are your "digital negatives" working
JPGs are the ultimately disposable files.
>
> I do, however, wonder that by working on raw format, one will end up
> spending much more time post processing after the photos are taken.
> This sometimes I do not have the luxury to do it. Therefore, I also
> look around with interest on what camera is doing better than the
> others (in terms of generating JPEG photos), or at least the
> processing that this particular camera is suit to your likings in
> colour, contrast, tones, etc.
That is one of the reasons to shoot RAW + JPG. That way you can have
quick access to the JPGs and make adjustments to select RAW files as
you choose. ...but you can only do that if you have the RAW file. Just
remember, any incamera adjustments are not going to effect the RAW
files, only the JPGs. So if a JPG is turns out not to your liking, the
RAW should be there to bail you out.
Also, as you develop a work flow you are comfortable with you will find
working with RAW will become quicker & quicker.
>
> I just have one question - if you take a photo which was out of focus,
> could you actually make it in focus when you have the raw files?
No. The RAW file is the record of the image captured in its purest
form, and if it is out of focus that lack of focus is part of the
permanant data for that image.
There is only so much you can fix.
>
> One more time, I thank you very much to all responders for the very
> useful discussion on this topic!
> Regards
--
Regards,
Savageduck
nospam
<f5d08d6c-2715-40e2...@g37g2000yqn.googlegroups.com>,
<anir...@gmail.com> wrote:
> I do, however, wonder that by working on raw format, one will end up
> spending much more time post processing after the photos are taken.
that's absolutely false.
with modern raw converters, there is *no* time penalty for shooting
raw, unless of course, you want to spend a lot of time tweaking it.
quite often, the default parameters are good enough, with maybe only a
minor tweak needed.
with some raw converters (e.g., lightroom), there isn't even a
difference in the workflow between raw or jpeg - you just give it
images from the camera and see the results on screen, adjust as needed,
print or upload to the 'net. it's same amount of time either way, but
if you shoot raw, the results will generally be better than if you
shoot jpeg. that's why it's somewhat of a waste to shoot raw+jpeg.
> I just have one question - if you take a photo which was out of focus,
> could you actually make it in focus when you have the raw files?
not really. it can be possible to undo it a little with very
sophisticated modeling of the lens and a lot of expensive software
though.
Eric Stevens
Floyd, I suspect you have been smoking something which is not good for
you. Subject to statistical error limitations, there is a one to one
correspondence between the source image and the RAW file. One can be
converted to the other using the rules inherent in the camera's
software. The data in the RAW file can't be restructured to make a
different image without changing the data.
Eric Stevens
Floyd L. Davidson
I've been looking at Dave Coffin's dcraw.c for years.
The first thing you find is a copyright notice, because
it is *not* Public Domain software and never has been.
>You need to tell dcraw to make absolutely plain
>(-d or -D, I forget which) TIFFS (-T) and, if cyou so desire,
>even gamma = 1.0.
>
>I did it this afternoon. You can see the difference colored
>pixels (different colors in the Bayer filter) in the
>monochrome (grayscale) TIFF file.
What's your point? The -d option generates a greyscale
image using individual sensor data without
interpolation. (As noted too, it might be useful for
documents, but not for color imagery.)
>And in the past I actually HAVE done the display that way, using
>software I wrote myself. (Convert TIFF to plain genuine "raw"
>bitmap using ImageMagick, then write a program to convert that
>to 24 bit color as I described above.)
>
>Could you exmplain how you could be so wrong?
You get an image that way and it is indeed generated
from the camera's data. It is not a viable alternative
to using an appropriate raw conversion process.
>Caveat: the dcraw code is dense. I have no 100% veridird what it does
>by looking at the code. Don't attack me on this point
>unless you have successfully understood the dcraw code which is
>executed using -D or -d.
I'll grant that Coffin does not write easily readable
code. However, it is also true that perhaps a majority
of third party RAW converters do in fact use the code
from dcraw.c. That includes UFRAW, which I use. (And I
wouldn't say the code for UFRAW is any easier to read
than ufraw.c...)
My point was that your comment about Public Domain
software was wrong, and your description of how to
generate an image might well produce something that is
recognizable, but it is not a useful way to generate
images from camera data.
Floyd L. Davidson
>Floyd, I suspect you have been smoking something which is not good for
>you. Subject to statistical error limitations, there is a one to one
>correspondence between the source image and the RAW file. One can be
>converted to the other using the rules inherent in the camera's
>software.
What do you mean by "the source image"?
Pehraps you need to study up on what a raw data file
is, and what a JPEG or TIFF image file is?
Do you know, for example, why the word "interpolation"
(see a good dictionary) is used to describe the process
of converting raw sensor data to an image format?
>The data in the RAW file can't be restructured to make a
>different image without changing the data.
That is not true. In fact there is far more data in a
raw file than is needed to make an image. Likewise it
is possible to emphasize different parts of the data in
different ways to get different images. That is exactly
what white balance is, for example.
It's also true that while I said that at least 9 sensor
locations are used to generate each pixel, there are
several variations on ways to interpolate the data that
use more than 9. Each method is different.
Did you read, and understand, the following few paragraphs?
>>A JPEG or TIFF file contains an image. The RAW file
>>contains data to make an image.
>>
>>For example, each "sensal" location on the sensor does
>>*not* translate to a single pixel in the resulting
>>image. Instead the data from at least 9 different
>>sensors locations is used to determine the Red, Green,
>>and Blue values for a single pixel.
>>
>>The process where all of that data is interpolated is
>>called "raw conversion", and is much the same as
>>converting a pile of nails and boards into a house.
If you understood that, then the above part that you
objected to should have made sense. If not, tell me
what you think it all is and I'll try to explain the
significance in a way that is directed at your response
(rather than at the OP for this thread).
Eric Stevens
Davidson) wrote:
Floyd has failed to point out that at this point he has omitted a
great deal of previous text. I know he has been around more than long
enough to know that this is not the right thing to do.
>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>Floyd, I suspect you have been smoking something which is not good for
>>you. Subject to statistical error limitations, there is a one to one
>>correspondence between the source image and the RAW file. One can be
>>converted to the other using the rules inherent in the camera's
>>software.
>
>What do you mean by "the source image"?
That which is projected onto the sensor by the lens.
>
>Pehraps you need to study up on what a raw data file
>is, and what a JPEG or TIFF image file is?
Perhaps I don't. Perhaps you need to explain what you are trying to
say, preferably without the aid of whatever it is you have snipped
from this article before replying.
>
>Do you know, for example, why the word "interpolation"
>(see a good dictionary) is used to describe the process
>of converting raw sensor data to an image format?
I know very well what is meant by the word 'interpolation' and the
manner in which this is carried out has nothing whatsoever to do with
the relationship between the source image and the RAW file except to
the extent that it is determined by the rules inherent in the camera's
software.
>
>>The data in the RAW file can't be restructured to make a
>>different image without changing the data.
>
>That is not true. In fact there is far more data in a
>raw file than is needed to make an image. Likewise it
>is possible to emphasize different parts of the data in
>different ways to get different images. That is exactly
>what white balance is, for example.
And a change in the white balance involves a change in the interpreted
RAW data: i.e. the white balance can only be changed by changing the
raw data.
>
>It's also true that while I said that at least 9 sensor
>locations are used to generate each pixel, there are
>several variations on ways to interpolate the data that
>use more than 9. Each method is different.
The sensor locations are irrelevant. The RAW data is derived from the
sensors by rules which are determined by the manufacturer of the
camera. The signals generated by the sensors are determined by the
rules inherent in the camera's software. As I have already said, there
is a one to one correspondence between the source image and the RAW
file. You don't have a choice of RAW files for a given image. Nor do
you have a choice of images for a given RAW file.
>
>Did you read, and understand, the following few paragraphs?
>
>>>A JPEG or TIFF file contains an image. The RAW file
>>>contains data to make an image.
>>>
>>>For example, each "sensal" location on the sensor does
>>>*not* translate to a single pixel in the resulting
>>>image. Instead the data from at least 9 different
>>>sensors locations is used to determine the Red, Green,
>>>and Blue values for a single pixel.
>>>
>>>The process where all of that data is interpolated is
>>>called "raw conversion", and is much the same as
>>>converting a pile of nails and boards into a house.
>
>If you understood that, then the above part that you
>objected to should have made sense. If not, tell me
>what you think it all is and I'll try to explain the
>significance in a way that is directed at your response
>(rather than at the OP for this thread).
JPEGs, TIFFs and RAW files all contain data required to create an
image. The principal difference is that the format of JPEGs and TIFFs
are independent of of the camera which created them while RAW files
are not.
Eric Stevens
Doug Jewell
> I am sorry if this topic may have been discussed too many times.
> However, I still have difficulties dealing with the concept of RAW
> files. Someone suggested that RAW files are like negatives, while-as
> JPEG files are like prints.
> My question is whether we can physically see a RAW file... I mean
> without placing it in the mercy of a software to open it as a JPEG
> file (and in the mean time, the software is doing the processing and
> converting it into JPEG using their own algorithm to produce what they
> consider to be the best JPEG. I agree that perhaps people should
> create both RAW and JPEG files when they take pictures.
card, CD, hard drive etc do you see the photo?
Whatever format a digital file is in, you need to do some
processing on it to convert it to a format you can see.
There are a couple of key differences between RAW & JPG -
Firstly, JPG is a standard. The standard specifies how the
data in the file is used to make the final photo. So with a
particular set of data, there is 1 way to turn it into a photo.
RAW (with the exception of the rarely used DNG format) is
not a standard. Each manufacturer has their own way of
laying out the data. Furthermore, each model has its own way
of laying out the data. Instead of the data being set down
in a standardised manner, it is very specific to the way
that particular make and model works.
Because JPG is a standard, you find that almost every piece
of software ever written that deals with image data can deal
with JPG images - including the kiosk software that modern
digital photo labs use.
RAW on the other hand requires specific decoders. If someone
wants to put RAW support in their program, they first need
to know the details of how the particular camera stores its
raw files. This information is sometimes not freely
available, so they need to pay license fees, sign NDA's etc.
When a new camera comes out they need to update their
software to support the new camera.
The other thing with RAW is what it stores. Once a JPG is
decompressed, it contains information that specifies the
exact RGB value that every pixel in the resulting image has.
RAW on the other hand contains the readout data from each
sensor element. Since each sensor element is either Red,
Green or Blue, a raw file only has one value for each
element, not the full RGB value. To get an RGB value to
display for viewing, it must take that value, and combine it
with the data from its neighbours to get a full colour
value. The proportions of the neighbours values, how many
neighbours etc that get used to make the final value will
depend on various parameters such as sharpness, contrast,
brightness, saturation, white-balance etc. The values of
these settings that were selected at the time of shooting
are stored in the raw file, but can be over-ridden. Likewise
there is no one right algorithm. Different algorithms will
yield different results - some may result in images with
slightly less detail but lower noise, or vice-versa, other
algorithms may give more accurate colour reproduction, etc.
As a result of these differences, there are comparatively
very few programs around that can view/print/edit a RAW
file, but they do exist. Theoretically it isn't entirely
necessary to convert to JPG/TIFF etc first, although in
practice that's how most tools work, because by converting
the image to one of the standard formats it then allows
greater flexibility.
As for shooting RAW+JPG, this offers the advantage that you
can preview/edit/print the JPG image using commonly
available software. The camera produces a usable JPG at
shooting time, so in many cases there is no need to
post-process. Browsing/viewing JPGs is also faster than
opening them in a RAW converter so it makes it much quicker
to go through and identify the "keepers". Then if you
ascertain that the image is good, you can then use the RAW
to tweak any settings that may not be quite 100% perfect.
>
> The next question is whether commercial photo processing softwares
> (Photoshop, Paintshop, Aperture, etc) treating RAW files produced from
> different brand cameras differently, as I noticed that the extension
> file name for RAW files differ from cameras to cameras. Can the
> special software made by the camera's manufacturer (which sometimes
> comes with the camera that you purchase) do a better job than the
> commercially photo processing softwares?
Yes the various programs can and in most cases do, process
differently to the in-camera convertor or the brand-name
software. Whether they do it better is a matter for debate
and personal taste. Pentax cameras for example are
frequently criticised for having soft in-camera JPGs.
Converting the RAW image with Adobe will overcome this
problem to create a very different image to what the
in-camera or Pentax branded software will produce.
>
> I recall that someone mentioned that the camera's processing engine is
> not as versatile as a computer's photo processing software, as well as
> the time to produce the JPEG file in the camera is relatively short.
> Therefore, built-in camera processing engine cannot make a better job
> than a real photo processing software. As processing speed is getting
> faster and faster, could a camera sometime in the future produces JPEG
> photos which are as good as or better than the commercial photo
> softwares?
The main difference is that in-camera does the conversion
based on settings made before you take the photo. When you
get the image to the computer, you can choose the conversion
settings in retrospect, which means you can choose the ideal
settings for the actual image, rather than settings for how
you anticipate the image. In many cases the computer based
software (especially the software that ships with the
camera) has basically the same options that the in-camera
system has, however because you are doing it after-the-fact
you can make better choices.
>
> Thanks for the discussions
--
Don't blame me - I didn't vote for Kevin Rudd or Anna Bligh!
Poldie
RAW isn't a standard - different companies store data in different
ways. The canon CR2 format (which has been reverse engineered and is
just a google away if you're interested in the technical details) is,
for the most part, a JPEG with compression disabled, plus a bunch of
other info describing colour, white balance etc, plus info about the
settings on the camera (but which can be overridden in a converter
such as Bibble or even the ones which come with the camera if people
actually use those). It's not actually raw sensor data, because
this isn't a great deal of use without further processing to
'demosaic' and do Baysian stuff to make up for the fact that some of
the data you want to see isn't actually there until you create it.
nospam
<4a224e81$0$32347$5a62...@per-qv1-newsreader-01.iinet.net.au>, Doug
Jewell <a...@and.maybe.ill.tell.you> wrote:
> RAW (with the exception of the rarely used DNG format) is
> not a standard. Each manufacturer has their own way of
> laying out the data. Furthermore, each model has its own way
> of laying out the data. Instead of the data being set down
> in a standardised manner, it is very specific to the way
> that particular make and model works.
dng is not all that rare and several cameras output it directly. also
the structure of a raw file is mostly standard, it's the contents that
vary with every camera since every camera is a little different (or a
lot different).
> Because JPG is a standard, you find that almost every piece
> of software ever written that deals with image data can deal
> with JPG images - including the kiosk software that modern
> digital photo labs use.
yep
> RAW on the other hand requires specific decoders. If someone
> wants to put RAW support in their program, they first need
> to know the details of how the particular camera stores its
> raw files. This information is sometimes not freely
> available, so they need to pay license fees, sign NDA's etc.
> When a new camera comes out they need to update their
> software to support the new camera.
or just let the operating system handle it.
> The other thing with RAW is what it stores. Once a JPG is
> decompressed, it contains information that specifies the
> exact RGB value that every pixel in the resulting image has.
> RAW on the other hand contains the readout data from each
> sensor element. Since each sensor element is either Red,
> Green or Blue, a raw file only has one value for each
> element, not the full RGB value. To get an RGB value to
> display for viewing, it must take that value, and combine it
> with the data from its neighbours to get a full colour
> value. The proportions of the neighbours values, how many
> neighbours etc that get used to make the final value will
> depend on various parameters such as sharpness, contrast,
> brightness, saturation, white-balance etc. The values of
> these settings that were selected at the time of shooting
> are stored in the raw file, but can be over-ridden. Likewise
> there is no one right algorithm. Different algorithms will
> yield different results - some may result in images with
> slightly less detail but lower noise, or vice-versa, other
> algorithms may give more accurate colour reproduction, etc.
yep
> As a result of these differences, there are comparatively
> very few programs around that can view/print/edit a RAW
> file, but they do exist. Theoretically it isn't entirely
> necessary to convert to JPG/TIFF etc first, although in
> practice that's how most tools work, because by converting
> the image to one of the standard formats it then allows
> greater flexibility.
actually there are quite a few apps that work with raw directly without
converting it to anything, including lightroom, photoshop and aperture.
> As for shooting RAW+JPG, this offers the advantage that you
> can preview/edit/print the JPG image using commonly
> available software. The camera produces a usable JPG at
> shooting time, so in many cases there is no need to
> post-process. Browsing/viewing JPGs is also faster than
> opening them in a RAW converter so it makes it much quicker
> to go through and identify the "keepers". Then if you
> ascertain that the image is good, you can then use the RAW
> to tweak any settings that may not be quite 100% perfect.
browsing jpegs used to be faster. today that's no longer the case.
thus, raw+jpeg is largely a waste.
nospam
<69173ac3-7fc0-448e...@p4g2000vba.googlegroups.com>,
Poldie <Pol...@gmail.com> wrote:
> RAW isn't a standard - different companies store data in different
> ways. The canon CR2 format (which has been reverse engineered and is
> just a google away if you're interested in the technical details) is,
> for the most part, a JPEG with compression disabled,
it's essentially a tiff, not a jpeg
> plus a bunch of
> other info describing colour, white balance etc, plus info about the
> settings on the camera (but which can be overridden in a converter
> such as Bibble or even the ones which come with the camera if people
> actually use those).
right, and only the camera maker's own software correctly reads those
settings. other software usually has its own set of defaults which may
or may not be better. any of them can be overridden.
> It's not actually raw sensor data, because
> this isn't a great deal of use without further processing to
> 'demosaic' and do Baysian stuff to make up for the fact that some of
> the data you want to see isn't actually there until you create it.
a raw file is definitely raw sensor data + the metadata for white
balance, etc., which must be processed to become something resembling
the original scene.
Poldie
> In article
> <69173ac3-7fc0-448e-8898-7abada472...@p4g2000vba.googlegroups.com>,
>
> Poldie <Pol...@gmail.com> wrote:
> > RAW isn't a standard - different companies store data in different
> > ways. The canon CR2 format (which has been reverse engineered and is
> > just a google away if you're interested in the technical details) is,
> > for the most part, a JPEG with compression disabled,
>
> it's essentially a tiff, not a jpeg
No, where I saw `for the most part` I'm referring to majority of the
data in the CR2 file - that which makes up the detail of the image (as
opposed to header into, thumbnail, colour tables etc). To the extent
that I understand an analysis of this foramt, it's essentially a
lossless JPEG.
nospam
<f2d93973-39e7-46cd...@e20g2000vbc.googlegroups.com>,
Poldie <Pol...@gmail.com> wrote:
> > > RAW isn't a standard - different companies store data in different
> > > ways. The canon CR2 format (which has been reverse engineered and is
> > > just a google away if you're interested in the technical details) is,
> > > for the most part, a JPEG with compression disabled,
> >
> > it's essentially a tiff, not a jpeg
>
> No, where I saw `for the most part` I'm referring to majority of the
> data in the CR2 file - that which makes up the detail of the image (as
> opposed to header into, thumbnail, colour tables etc). To the extent
> that I understand an analysis of this foramt, it's essentially a
> lossless JPEG.
there is an embedded jpeg, independent of the raw data.
Floyd L. Davidson
>On Sat, 30 May 2009 21:32:27 -0800, fl...@apaflo.com (Floyd L.
>Davidson) wrote:
>
>Floyd has failed to point out that at this point he has omitted a
>great deal of previous text. I know he has been around more than long
>enough to know that this is not the right thing to do.
I've been posting on Usenet for over 20 years Eric, and
I do know that snipping out the part not being commented
on is the right way to edit an article before posting.
When are *you* going to learn that?
>>>you. Subject to statistical error limitations, there is a one to one
>>>correspondence between the source image and the RAW file. One can be
>>>converted to the other using the rules inherent in the camera's
>>>software.
>>
>>What do you mean by "the source image"?
>
>That which is projected onto the sensor by the lens.
Then your statements above are patently silly on their face.
The raw data is a sampled set drawn from the projected image.
The projected image cannot ever be recreated in its entirety,
nor can the samples even be recreated with precision.
>Perhaps you need to explain what you are trying to
>say, preferably without the aid of whatever it is you have snipped
>from this article before replying.
I certainly have not used text that isn't here, and
don't see how that would be possible!
>>Do you know, for example, why the word "interpolation"
>>(see a good dictionary) is used to describe the process
>>of converting raw sensor data to an image format?
>
>I know very well what is meant by the word 'interpolation' and the
>manner in which this is carried out has nothing whatsoever to do with
>the relationship between the source image and the RAW file except to
>the extent that it is determined by the rules inherent in the camera's
>software.
You said the "source image" is what is projected on the
sensor. Interpolation of course is the method by which
the sensor data is converted to an image format for
viewing.
Two very distinctly separate relationships.
>>>The data in the RAW file can't be restructured to make a
>>>different image without changing the data.
>>
>>That is not true. In fact there is far more data in a
>>raw file than is needed to make an image. Likewise it
>>is possible to emphasize different parts of the data in
>>different ways to get different images. That is exactly
>>what white balance is, for example.
>
>And a change in the white balance involves a change in the interpreted
>RAW data: i.e. the white balance can only be changed by changing the
>raw data.
It is quite possible to change the raw data to effect
while balance, but it isn't normally done that way (Nikon,
for example, has hinted that they might be doing exactly
that in hardware).
What is changed is the interpolation of the data when
creating an image format. The raw data is not changed,
and the raw file stays exactly the same. The way the
data is manipulated during interpolation changes.
Regardless of that, it is rather easy to demonstrate
that the raw data is not changed in order to adjust
white balance. Merely convert a RAW file to a JPEG
image and then, using only the JPEG image (which
contains vastly less data that the RAW file), use an
editor to change the white balance and write a new JPEG
file with a different white balance. The raw data is
not even used, much less changed.
>>It's also true that while I said that at least 9 sensor
>>locations are used to generate each pixel, there are
>>several variations on ways to interpolate the data that
>>use more than 9. Each method is different.
>
>The sensor locations are irrelevant. The RAW data is derived from the
>sensors by rules which are determined by the manufacturer of the
>camera.
False. Every different raw converter design uses a
different set of "rules". Coffin's dcraw.c uses one
set, Nikon uses another, and several other raw
converters are different from both of those.
The sensor locations are hardly irrelevant either. As I
said, at least *nine* of them are used to generate each
pixel in the resulting image, and you can be assured the
location is relevant! It isn't one pixel and then 8
other randomly chosen locations... it's a group of 9
(or more).
>The signals generated by the sensors are determined by the
>rules inherent in the camera's software.
They are determined by rules inherent in the camera's
hardware. The sensor is not manipulated by software
other than clearing it and reading it. A given amount
of light on one sensor locations produces *exactly* the
same output from the sensor regardless of the camera's
software.
>As I have already said, there
>is a one to one correspondence between the source image and the RAW
>file.
You can say that all you like, but it still requires at
least *nine* different sensor locations to generate data
for each pixel of the resulting image. It is not a one
to one relationship.
>You don't have a choice of RAW files for a given image. Nor do
>you have a choice of images for a given RAW file.
But you have a choice of an infinite number of resulting
images when the camera raw data is interpolated. None
of them are exactly the same as your "source image" that
was projected onto the sensor.
>>If you understood that, then the above part that you
>>objected to should have made sense. If not, tell me
>>what you think it all is and I'll try to explain the
>>significance in a way that is directed at your response
>>(rather than at the OP for this thread).
>
>JPEGs, TIFFs and RAW files all contain data required to create an
>image.
A JPEG or TIFF contains the data for a single image. A
RAW file contains information for something approaching
an infinite number of images.
>The principal difference is that the format of JPEGs and TIFFs
>are independent of of the camera which created them while RAW files
>are not.
The JPEG and TIFF images are no more, or less,
independent of the camera than the RAW data.
Chris H
<fl...@apaflo.com> writes
I think we have a confusion over terminology
RAW files are the RAW sensor data with a meta file and usually an
embedded Jpg for viewing.
As pointed out the actual format of the RAW files depends on the
sensors etc and is normally specific to a manufacturer or a range of its
cameras.
The information on the formats is not Open Source or Public Domain but
the source and or libraries and or formats ARE freely available. I have
the information and software for the Ninkon Raw format.
However whilst it is free to download, just as with GNU, Open Source and
any other software there is a licence.
This is why there are many programs under many licences and costs that
will handle RAW files from most manufacturers.
With the RAW data you can apply the settings that were in the camera
when the picture was taken or change them. This gives you the
opportunity to "re-take" the photo on the computer +/- 3 stops
(depending on your RAW processor) Some such as DxO can even adjust for
lens characteristics.
So you can from a RAW file produce a series of jpegs with different F
stops and white balance settings as though you were still where you took
the picture with the camera.
As such it is more versatile than a conventional negative
If you process the RAW file and turn out a TIFF which is loss less that
TIFF is more like a film negative. Than you can apply "dark room "
techniques on the TIFF to produce prints in Photoshop which is the
equivalent of a darkroom.
The RAW processor is a NEW step in digital photography that gives more
flexibility
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris H
<fl...@apaflo.com> writes
I think we have a problem with definitions here.
What do you define as "Public Domain"?
Most public domain software has a copy right or license of one sort or
another. In fact I don't know of any that does not.
Floyd L. Davidson
CR2 is a TIFF file format. Actually, most RAW formats
are, including Canon's CRW and all of Nikon's NEF
formats. What they do not necessarily do is use TIFF
data formats or stick only to TIFF tags. It's the
structure of the files that are TIFF.
Here is one description of the CR2 format:
http://wildtramper.com/sw/cr2/cr2.html
Floyd L. Davidson
"Public Domain" means "The total absence of copyright
protection."
In fact, you cannot know of any Public Domain software
that is copyrighted or requires a license to use.
Of course the laws regarding how a work becomes Public
Domain vary from country to country. In the US today it
is relatively difficult for a private individual to
produce Public Domain software! Years ago it merely
meant not explicitly copyrighting something, but we
changed our laws to make copyright automatic, and at the
same time we made it so that it is putting a work in the
Public Domain that requires an explicit (written I
believe, but don't quote me on that) statement.
Poldie
Yeah, I know. TIFF info identifying where to find the actual
photograph data, which is JPEG lossless format - the latter being the
interesting, relevant part for people wondering whether or not the
data is compressed, lossless etc.
nospam
<7369029d-1f67-41be...@l28g2000vba.googlegroups.com>,
Poldie <Pol...@gmail.com> wrote:
> Yeah, I know. TIFF info identifying where to find the actual
> photograph data, which is JPEG lossless format - the latter being the
> interesting, relevant part for people wondering whether or not the
> data is compressed, lossless etc.
again, no. there is an embedded jpeg that's completely separate from
the raw data and it's an ordinary lossy jpeg. there may even be more
than just one embedded jpeg, i.e., a full size and a thumbnail.
"mcdonaldREMOVE TO...@scs.uiuc.edu
> Floyd L. Davidson wrote:
>> "mcdonaldREMOVE TO ACTUALLY REACH ME"@scs.uiuc.edu wrote:
>>> The answer is, at least for Canon, yes. There is public
>>> domain software available that will convert the data, which is
>>> intensity data at each pixel, into a pixel-for-pixel file, that is,
>>> 8 or 12 or 14 bits per pixel. This is not full color, it
>>> is filtered by the Bayer filter >>>
Here is such a file, converted to TIFF by dcraw and then to 24 bit .bmp
by Photoshop. You can look at it. Blow it up to 200% or larger
and you will see the Bayer matrix.
http://www.scs.uiuc.edu/~mcdonald/IMG_2706.bmp
note: Unix, so it is case-sensitive
>>> You can then take that file and make a 24 bit file from it, by
>>> moving red pixel values to the red byte, blue ones to the
>>> blue byte, and green ones to the green byte, leaving the other
>>> two bytes of each 24 bit number zero. This can then
>>> be displayed on you computer. To get the color right you need to
>>> scale the
>>> R, G, and B numbers correctly. It will display as
>>> a color image, albeit rather dark since each pixel will
>>> be mostly black.
and here is this:
http://www.scs.uiuc.edu/~mcdonald/rgb_2706.bmp
It does not display well because it is so dark.
>>>
>>> I've done it, it works.
And finally, I used the Photoshop blur function on that to
do a VERY CRUDE conversion to what Davidson would call an "image"
and here it is:
http://www.scs.uiuc.edu/~mcdonald/blur_2706.bmp
Note that this was lightened up and color-temperature corrected in Photoshop.
It does not look as "peppy" and colored as the default Photoshop
or Canon Digital Photo Professional conversion does, but it looks
remarkably like what you get if Digital Photo Professional
is set to "faithful", including those grayish green leaves.
Doug McDonald
"mcdonaldREMOVE TO...@scs.uiuc.edu
>
> My point was that your comment about Public Domain
> software was wrong,
That is true ... the words should be changed to "free".
and your description of how to
> generate an image might well produce something that is
> recognizable, but it is not a useful way to generate
> images from camera data.
>
Oh, agreed. I was tyring to explain things!
See my other post where I actually did it and present the results.
Yes, they are of course not "presentable" but are good examples
of how it works.
Doug McDonald
Rob Morley
Huge <Hu...@nowhere.much.invalid> wrote:
> On 2009-05-31, Floyd L. Davidson <fl...@apaflo.com> wrote:
>
> > "Public Domain" means "The total absence of copyright
> > protection."
>
> In which case, there can be no "public domain" software, since
> copyright exists on all works, whether explicitly claimed or not.
>
The truth falls somewhere between the two - FLD should have said "total
absence of copyright" rather than "total absence of copyright
protection", while you should remember that it is possible for the
holder of copyright to surrender it, thus putting his work in the
public domain.
Rob Morley
Shawn Hirn <sr...@comcast.net> wrote:
> If your computer supports the format your photos are in, then the
> photos can be seen. On my Mac, most cameras' raw files are seen
> without software the same as more common formats such as jpg and gif,
> NBD.
>
That's because the software for displaying various graphics formats is
built into the MAC file manager, not because there isn't any software
doing the work.
Savageduck
> In article
> <8eff0e4e-0aad-4415...@j12g2000vbl.googlegroups.com>,
> If your computer supports the format your photos are in, then the photos
> can be seen. On my Mac, most cameras' raw files are seen without
> software the same as more common formats such as jpg and gif, NBD.
Not entirely true.
OSX doesn't miraculously allow the image to appeare on your display.
The "thumbnail" you see in the finder is the inbedded jpg.
Preview is actually "software." and the RAW decoder is part of the OS
and the iPhoto/Preview/Aperture package, all of which are updated to
include the ability to decode RW file for support of new cameras, just
as ACR is updated.
>
> The best way to learn about what RAW files do for you is to switch your
> camera to raw mode and start shooting photos, then transfer the image
> files to your computer and work with them.
Exactly.
--
Regards,
Savageduck
John McWilliams
True, but everything you see on any computer is a result of software, be
it built into the O/S, or later installed.
And, it's "Mac"; MAC stands for other stuff, and is an acronym.
--
John McWilliams
nospam
Savageduck <savageduck1{REMOVESPAM}@me.com> wrote:
> > If your computer supports the format your photos are in, then the photos
> > can be seen. On my Mac, most cameras' raw files are seen without
> > software the same as more common formats such as jpg and gif, NBD.
>
> Not entirely true.
> OSX doesn't miraculously allow the image to appeare on your display.
it's basically true.
> The "thumbnail" you see in the finder is the inbedded jpg.
finder is just one app and what it does is not necessarily what other
apps do. if you're referring to quicklook, what gets displayed depends
on the plugin.
> Preview is actually "software." and the RAW decoder is part of the OS
> and the iPhoto/Preview/Aperture package, all of which are updated to
> include the ability to decode RW file for support of new cameras, just
> as ACR is updated.
the raw decoding is part of the os and is available to *any* code that
supports displaying images. if an app supports reading images at all,
it can get all formats for free, including raw. when the os is updated
for new cameras, then the apps automatically support them.
Savageduck
...and the OS isn't software??
--
Regards,
Savageduck
Floyd L. Davidson
>On 2009-05-31, Floyd L. Davidson <fl...@apaflo.com> wrote:
>
>> protection."
>
>on all works, whether explicitly claimed or not.
That is absolutely not true. Nothing written prior to 1923
is copyrighted. Nothing produced by the US government is
copyrighted. Nothing written prior to 1978 that was not explicitly
copyrighted is now.
And nothing that you explicitly remove your copyright from is
copyrighted.
Those are all in in the Public Domain.
>> In fact, you cannot know of any Public Domain software
>> that is copyrighted or requires a license to use.
>>
>> Of course the laws regarding how a work becomes Public
>> Domain vary from country to country. In the US today it
>> is relatively difficult for a private individual to
>> produce Public Domain software! Years ago it merely
>> meant not explicitly copyrighting something, but we
>> changed our laws to make copyright automatic,
>
>IOW you decided to comply with the Berne Convention, along with the
>civilised parts of the World.
Sheesh, the US was compliant prior to that.
Can't you get anything right?
Floyd L. Davidson
I quoted a dictionary, why would I add something it didn't say,
and that is not needed?
Floyd L. Davidson
You should have read the URL that I cited. It says the file format
is TIFF, and that it contains 4 each IFD's. The 4th IFD contains
"JPEG data (lossless compression)" for the raw data.
Chris H
<fl...@apaflo.com> writes
>Chris H <ch...@phaedsys.org> wrote:
>>
>>What do you define as "Public Domain"?
>>
>>Most public domain software has a copy right or license of one sort or
>>another. In fact I don't know of any that does not.
>
>"Public Domain" means "The total absence of copyright
>protection."
Then that is different to the rest of the world.
>In fact, you cannot know of any Public Domain software
>that is copyrighted or requires a license to use.
In FACT. I do. I have a whole CD of it. PD software was quite common 15
years ago. PD SW along with Shareware was often on the disks and CD's
with computer magazines.
>Of course the laws regarding how a work becomes Public
>Domain vary from country to country. In the US today it
>is relatively difficult for a private individual to
>produce Public Domain software!
Not true in the legal sense. Only true by your personal definition.
> Years ago it merely
>meant not explicitly copyrighting something,
Nope... All the PD SW I have is labelled as PD and has copyright and
licenses.
>but we
>changed our laws to make copyright automatic,
I think you changed your laws to fit in with the rest of the world. (Who
had and still have PD SW. )
Floyd L. Davidson
I see that we are in agreement. It isn't Public Domain and
your method works like shit.
nospam
<fl...@apaflo.com> wrote:
> >> Yeah, I know. TIFF info identifying where to find the actual
> >> photograph data, which is JPEG lossless format - the latter being the
> >> interesting, relevant part for people wondering whether or not the
> >> data is compressed, lossless etc.
> >
> >again, no. there is an embedded jpeg that's completely separate from
> >the raw data and it's an ordinary lossy jpeg. there may even be more
> >than just one embedded jpeg, i.e., a full size and a thumbnail.
>
> You should have read the URL that I cited. It says the file format
> is TIFF, and that it contains 4 each IFD's. The 4th IFD contains
> "JPEG data (lossless compression)" for the raw data.
i did look at it but apparently not close enough. that's very odd.
nospam
sure, but the point is that any app can read raw files without
installing anything special. if an app can display jpegs it can
display nikon and canon raw with no additional code.
Floyd L. Davidson
>In message <871vq5o...@apaflo.com>, Floyd L. Davidson
><fl...@apaflo.com> writes
>>Chris H <ch...@phaedsys.org> wrote:
>>>
>>>What do you define as "Public Domain"?
>>>
>>>Most public domain software has a copy right or license of one sort or
>>>another. In fact I don't know of any that does not.
>>
>>"Public Domain" means "The total absence of copyright
>>protection."
>
>Then that is different to the rest of the world.
No, that is quoted from a dictionary, and it happens to
be the same meaning that it has in the UK. And yes I did
a bit of research to verify that.
You need to research this topic rather than spouting
off with nonsense.
>>In fact, you cannot know of any Public Domain software
>>that is copyrighted or requires a license to use.
>
>In FACT. I do. I have a whole CD of it. PD software was quite common 15
>years ago. PD SW along with Shareware was often on the disks and CD's
>with computer magazines.
Look, get this one part of it straight: If it is PD it
does not have copyright protection and can be used
without any form of license at all.
Shareware is copyrighted, and is not in the Public
Domain.
>>Of course the laws regarding how a work becomes Public
>>Domain vary from country to country. In the US today it
>>is relatively difficult for a private individual to
>>produce Public Domain software!
>
>Not true in the legal sense. Only true by your personal definition.
That is not my personal definition. That is the legal
term of art definition.
>> Years ago it merely
>>meant not explicitly copyrighting something,
>
>Nope... All the PD SW I have is labelled as PD and has copyright and
>licenses.
"Article VII. This Convention shall not apply to
works or rights in works which, at the effective date
of this Convention in a Contracting State where
protection is claimed, are permanently in the public
domain in the said Contracting State."
If you read that carefully it clearly shows that the
Berne Convention does not provide copyright protection
to works that are in the Public Domain... by definition.
(The cite is Article 4 of the "Universal Copyright
Convention As Revised At Paris On 24 July 1971". I.e.,
the Berne Convention.)
>>but we
>>changed our laws to make copyright automatic,
>
>I think you changed your laws to fit in with the rest of the world. (Who
>had and still have PD SW. )
The Berne Convention was not implemented in the UK until
1988, even though they signed it in 1887. The last
revision the the Convention was in Paris in 1971 (and
ammended in 1979). The US was not compliant until March
1989, less than one year after the UK.
Floyd L. Davidson
That is not true.
The app might well be able to display the embedded JPEG,
but it cannot display an image from the raw data itself
without additional code to convert it. That conversion
can (and probably would) create a distinctly different
image than the embedded JPEG.
nospam
<fl...@apaflo.com> wrote:
> >sure, but the point is that any app can read raw files without
> >installing anything special. if an app can display jpegs it can
> >display nikon and canon raw with no additional code.
>
> That is not true.
it very definitely is true.
> The app might well be able to display the embedded JPEG,
> but it cannot display an image from the raw data itself
> without additional code to convert it.
the additional code is built into the operating system. absent some
user specified parameters, it will use predefined defaults. the app
can also specify whether it wants the jpeg or the raw, and can also
provide controls to tweak the image.
> That conversion
> can (and probably would) create a distinctly different
> image than the embedded JPEG.
yea and? neither one is a 100% exact rendition of the original scene.
maybe the jpeg is better, maybe it isn't. if it's that important,
write the app to display both and let the user decide.
Eric Stevens
Davidson) wrote:
>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>On Sat, 30 May 2009 21:32:27 -0800, fl...@apaflo.com (Floyd L.
>>Davidson) wrote:
>>>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>
>>Floyd has failed to point out that at this point he has omitted a
>>great deal of previous text. I know he has been around more than long
>>enough to know that this is not the right thing to do.
>
>I've been posting on Usenet for over 20 years Eric, and
>I do know that snipping out the part not being commented
>on is the right way to edit an article before posting.
I wasn't complaining about you deleting the text. It was your failure
to point out that you have deleted text, which I criticised.
>When are *you* going to learn that?
When are you going to mark your deletions.
>
>>>>you. Subject to statistical error limitations, there is a one to one
>>>>correspondence between the source image and the RAW file. One can be
>>>>converted to the other using the rules inherent in the camera's
>>>>software.
>>>
>>>What do you mean by "the source image"?
>>
>>That which is projected onto the sensor by the lens.
>
>Then your statements above are patently silly on their face.
>
>The raw data is a sampled set drawn from the projected image.
>The projected image cannot ever be recreated in its entirety,
>nor can the samples even be recreated with precision.
What do you think I meant by 'statisticsl error limitations'?
>
>>Perhaps you need to explain what you are trying to
>>say, preferably without the aid of whatever it is you have snipped
>>from this article before replying.
>
>I certainly have not used text that isn't here, and
>don't see how that would be possible!
Yet you claim it is possible to create an image from data that isn't
there!
>
>>>Do you know, for example, why the word "interpolation"
>>>(see a good dictionary) is used to describe the process
>>>of converting raw sensor data to an image format?
>>
>>I know very well what is meant by the word 'interpolation' and the
>>manner in which this is carried out has nothing whatsoever to do with
>>the relationship between the source image and the RAW file except to
>>the extent that it is determined by the rules inherent in the camera's
>>software.
>
>You said the "source image" is what is projected on the
>sensor. Interpolation of course is the method by which
>the sensor data is converted to an image format for
>viewing.
That's part of what I meant when I wrote of "the rules inherent in the
camera's software".
>
>Two very distinctly separate relationships.
>
>>>>The data in the RAW file can't be restructured to make a
>>>>different image without changing the data.
>>>
>>>That is not true. In fact there is far more data in a
>>>raw file than is needed to make an image. Likewise it
>>>is possible to emphasize different parts of the data in
>>>different ways to get different images. That is exactly
>>>what white balance is, for example.
>>
>>And a change in the white balance involves a change in the interpreted
>>RAW data: i.e. the white balance can only be changed by changing the
>>raw data.
>
>It is quite possible to change the raw data to effect
>while balance, but it isn't normally done that way (Nikon,
>for example, has hinted that they might be doing exactly
>that in hardware).
... and therefore it is a different image. But nevertheless there is
only the one image which can be created from a set of unmodified raw
data.
>
>What is changed is the interpolation of the data when
>creating an image format. The raw data is not changed,
>and the raw file stays exactly the same. The way the
>data is manipulated during interpolation changes.
An interpolated data set is a new data set.
>
>Regardless of that, it is rather easy to demonstrate
>that the raw data is not changed in order to adjust
>white balance. Merely convert a RAW file to a JPEG
>image and then, using only the JPEG image (which
>contains vastly less data that the RAW file), use an
>editor to change the white balance and write a new JPEG
>file with a different white balance. The raw data is
>not even used, much less changed.
But only the one JPEG can be created from the RAW data providing the
rules of the transformation do not change.
>
>>>It's also true that while I said that at least 9 sensor
>>>locations are used to generate each pixel, there are
>>>several variations on ways to interpolate the data that
>>>use more than 9. Each method is different.
>>
>>The sensor locations are irrelevant. The RAW data is derived from the
>>sensors by rules which are determined by the manufacturer of the
>>camera.
>
>False. Every different raw converter design uses a
>different set of "rules". Coffin's dcraw.c uses one
>set, Nikon uses another, and several other raw
>converters are different from both of those.
But they are working on the camera's saved RAW file, not the
relationship between what the sensor sees and the saved RAW file.
>
>The sensor locations are hardly irrelevant either. As I
>said, at least *nine* of them are used to generate each
>pixel in the resulting image, and you can be assured the
>location is relevant! It isn't one pixel and then 8
>other randomly chosen locations... it's a group of 9
>(or more).
So?
>
>>The signals generated by the sensors are determined by the
>>rules inherent in the camera's software.
>
>They are determined by rules inherent in the camera's
>hardware. The sensor is not manipulated by software
>other than clearing it and reading it. A given amount
>of light on one sensor locations produces *exactly* the
>same output from the sensor regardless of the camera's
>software.
I should have said "The signals generated by the sensors are
-interpreted- by the rules inherent in the camera's software". To that
extent they are 'determined'.
>
>>As I have already said, there
>>is a one to one correspondence between the source image and the RAW
>>file.
>
>You can say that all you like, but it still requires at
>least *nine* different sensor locations to generate data
>for each pixel of the resulting image. It is not a one
>to one relationship.
I see the problem. You misunderstand what I mean by 'one to one'. By
that expression I mean that one imgage transforms into one RAW data
set. Its not as though the transformation entails (say) a quadratic
equation where the one image can give rise to either one of two RAW
data sets. See http://www.yourdictionary.com/one-to-one
>
>>You don't have a choice of RAW files for a given image. Nor do
>>you have a choice of images for a given RAW file.
>
>But you have a choice of an infinite number of resulting
>images when the camera raw data is interpolated. None
>of them are exactly the same as your "source image" that
>was projected onto the sensor.
... and none of them are the image defined by the RAW data. Close,
maybe, but not exact.
>
>>>If you understood that, then the above part that you
>>>objected to should have made sense. If not, tell me
>>>what you think it all is and I'll try to explain the
>>>significance in a way that is directed at your response
>>>(rather than at the OP for this thread).
>>
>>JPEGs, TIFFs and RAW files all contain data required to create an
>>image.
>
>A JPEG or TIFF contains the data for a single image. A
>RAW file contains information for something approaching
>an infinite number of images.
>
>>The principal difference is that the format of JPEGs and TIFFs
>>are independent of of the camera which created them while RAW files
>>are not.
>
>The JPEG and TIFF images are no more, or less,
>independent of the camera than the RAW data.
Eric Stevens
Floyd L. Davidson
>In article <87vdnhk...@apaflo.com>, Floyd L. Davidson
><fl...@apaflo.com> wrote:
>
>> >sure, but the point is that any app can read raw files without
>> >installing anything special. if an app can display jpegs it can
>> >display nikon and canon raw with no additional code.
>>
>> That is not true.
>
>it very definitely is true.
>
>> The app might well be able to display the embedded JPEG,
>> but it cannot display an image from the raw data itself
>> without additional code to convert it.
>
>the additional code is built into the operating system. absent some
>user specified parameters, it will use predefined defaults. the app
>can also specify whether it wants the jpeg or the raw, and can also
>provide controls to tweak the image.
Sure, the OS has a built in raw conversion program for the
cameras that will be released next year with new formats...
You just want it to be so great... that you'll claim *anything*,
even if it is abjectly absurd.
>> That conversion
>> can (and probably would) create a distinctly different
>> image than the embedded JPEG.
>
>yea and? neither one is a 100% exact rendition of the original scene.
>maybe the jpeg is better, maybe it isn't. if it's that important,
>write the app to display both and let the user decide.
Exactly. It requires an application. An OS does *NOT* have
raw conversion software built into it.
Poldie
> In article <87hbz1m7cb....@apaflo.com>, Floyd L. Davidson
Odd? It's what I've been saying, over and over again.
Floyd L. Davidson
>On Sun, 31 May 2009 03:10:56 -0800, fl...@apaflo.com (Floyd L.
>Davidson) wrote:
>When are you going to mark your deletions.
You still haven't figured out how it works, have you.
>What do you think I meant by 'statisticsl error limitations'?
You meant to imply that using big words with no meaning
will make it sound like you understand something you
don't. But anyone who does understand the process can
see that you don't.
>Yet you claim it is possible to create an image from data that isn't
>there!
I have never said any such thing, and see no point in you
making up distortions rather than discussion the topic at
hand.
>>You said the "source image" is what is projected on the
>>sensor. Interpolation of course is the method by which
>>the sensor data is converted to an image format for
>>viewing.
>
>That's part of what I meant when I wrote of "the rules inherent in the
>camera's software".
And you haven't yet figure out that one is the input to while
the other is an output from.
>>It is quite possible to change the raw data to effect
>>while balance, but it isn't normally done that way (Nikon,
>>for example, has hinted that they might be doing exactly
>>that in hardware).
>
>... and therefore it is a different image. But nevertheless there is
>only the one image which can be created from a set of unmodified raw
>data.
But clearly that is not true. The raw data set does not
define one single image. It can be interpolated to
produce an image. But the interpolation can be done in
a nearly infinite number of ways, each of which produces
a *different* image. No one way is the _right_ way,
they are all just as correct as the next.
>>What is changed is the interpolation of the data when
>>creating an image format. The raw data is not changed,
>>and the raw file stays exactly the same. The way the
>>data is manipulated during interpolation changes.
>
>An interpolated data set is a new data set.
The interpolation does not produce a new raw data set.
It produces an unique image.
>But only the one JPEG can be created from the RAW data providing the
>rules of the transformation do not change.
There is no one set of correct "rules of the
transformation".
>>False. Every different raw converter design uses a
>>different set of "rules". Coffin's dcraw.c uses one
>>set, Nikon uses another, and several other raw
>>converters are different from both of those.
>
>But they are working on the camera's saved RAW file, not the
>relationship between what the sensor sees and the saved RAW file.
Exactly. So why are you claiming otherwise? The raw
data set is not changed. But there are multiple,
correct, different sets of rules used to generate an
exact image from the raw data.
>>The sensor locations are hardly irrelevant either. As I
>>said, at least *nine* of them are used to generate each
>>pixel in the resulting image, and you can be assured the
>>location is relevant! It isn't one pixel and then 8
>>other randomly chosen locations... it's a group of 9
>>(or more).
>
>So?
So please cease this silliness where you claim the
sensor locations are irrelevant.
>>>The signals generated by the sensors are determined by the
>>>rules inherent in the camera's software.
>>
>>They are determined by rules inherent in the camera's
>>hardware. The sensor is not manipulated by software
>>other than clearing it and reading it. A given amount
>>of light on one sensor locations produces *exactly* the
>>same output from the sensor regardless of the camera's
>>software.
>
>I should have said "The signals generated by the sensors are
>-interpreted- by the rules inherent in the camera's software". To that
>extent they are 'determined'.
I quoted you exactly above. Now you want to change what
you said.
Regardless, you are still wrong. The signals from the
sensor are interpreted according to *hardware* and the
resulting data set is written to a RAW file format.
That is what is "interpreted" by software.
>>>As I have already said, there
>>>is a one to one correspondence between the source image and the RAW
>>>file.
>>
>>You can say that all you like, but it still requires at
>>least *nine* different sensor locations to generate data
>>for each pixel of the resulting image. It is not a one
>>to one relationship.
>
>I see the problem. You misunderstand what I mean by 'one to one'. By
>that expression I mean that one imgage transforms into one RAW data
>set. Its not as though the transformation entails (say) a quadratic
>equation where the one image can give rise to either one of two RAW
>data sets. See http://www.yourdictionary.com/one-to-one
So you now admit that it is not software at all, but a
hard wired hardware transform.
By next weekend we may force you into writing something
that is clear enough to make some sense.
>>>You don't have a choice of RAW files for a given image. Nor do
>>>you have a choice of images for a given RAW file.
>>
>>But you have a choice of an infinite number of resulting
>>images when the camera raw data is interpolated. None
>>of them are exactly the same as your "source image" that
>>was projected onto the sensor.
>
>... and none of them are the image defined by the RAW data. Close,
>maybe, but not exact.
That is precisely what I've been trying to get through
your head! Good. Now you can get on with a sane
discusssion of raw data processing.
The raw data does not define one specific image. When
the data is interpolated there is then an image!
ray
> Thanks for the discussions
I don't quite understand your question - you can't 'see' photos from any
file without some software to put it on the screen or print it out. I
suspect you have a very rudimentary understanding of the mechanics
involved. As I understand it, rather than having a matrix of red, green
and blue pixels as on a computer monitor, the sensor in most digital
cameras (probably all) is 'mosaiced' one line will have alternating red
and green and the next line will be green and blue. In order to make a
usable image the data must be 'demosaiced' and converted into a more
normal RGB representation - perhaps that's what you're getting at, so I
think the answer you're looking for is: no, it can't be viewed until it
has been de-mosaiced.
Eric Stevens
Davidson) set out to change the substance of the discussion by
massively editing the article to which he is responding. He is alos
trying to switch the argument from the relationship of the original
image to the RAW file to the relationship of the original image to the
raw data (which is quite different from the content of the RAW file).
>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>On Sun, 31 May 2009 03:10:56 -0800, fl...@apaflo.com (Floyd L.
>>Davidson) wrote:
--- [Unmarked text deletion by Floyd Davison] -----
>>When are you going to mark your deletions.
--- [Unmarked text deletion by Floyd Davison] -----
>
>You still haven't figured out how it works, have you.
--- [Unmarked text deletion by Floyd Davison] -----
>
>>What do you think I meant by 'statisticsl error limitations'?
>
>You meant to imply that using big words with no meaning
>will make it sound like you understand something you
>don't. But anyone who does understand the process can
>see that you don't.
--- [Unmarked text deletion by Floyd Davison] -----
>
>>Yet you claim it is possible to create an image from data that isn't
>>there!
>
>I have never said any such thing, and see no point in you
>making up distortions rather than discussion the topic at
>hand.
--- [Unmarked text deletion by Floyd Davison] -----
>
>>>You said the "source image" is what is projected on the
>>>sensor. Interpolation of course is the method by which
>>>the sensor data is converted to an image format for
>>>viewing.
>>
>>That's part of what I meant when I wrote of "the rules inherent in the
>>camera's software".
>
>And you haven't yet figure out that one is the input to while
>the other is an output from.
--- [Unmarked text deletion by Floyd Davison] -----
>
>>>It is quite possible to change the raw data to effect
>>>while balance, but it isn't normally done that way (Nikon,
>>>for example, has hinted that they might be doing exactly
>>>that in hardware).
>>
>>... and therefore it is a different image. But nevertheless there is
>>only the one image which can be created from a set of unmodified raw
>>data.
>
>But clearly that is not true. The raw data set does not
>define one single image. It can be interpolated to
>produce an image. But the interpolation can be done in
>a nearly infinite number of ways, each of which produces
>a *different* image. No one way is the _right_ way,
>they are all just as correct as the next.
>
>>>What is changed is the interpolation of the data when
>>>creating an image format. The raw data is not changed,
>>>and the raw file stays exactly the same. The way the
>>>data is manipulated during interpolation changes.
>>
>>An interpolated data set is a new data set.
--- [Unmarked text deletion by Floyd Davison] -----
>
>The interpolation does not produce a new raw data set.
>It produces an unique image.
>
>>But only the one JPEG can be created from the RAW data providing the
>>rules of the transformation do not change.
>
>There is no one set of correct "rules of the
>transformation".
--- [Unmarked text deletion by Floyd Davison] -----
>
>>>False. Every different raw converter design uses a
>>>different set of "rules". Coffin's dcraw.c uses one
>>>set, Nikon uses another, and several other raw
>>>converters are different from both of those.
>>
>>But they are working on the camera's saved RAW file, not the
>>relationship between what the sensor sees and the saved RAW file.
>
>Exactly. So why are you claiming otherwise? The raw
>data set is not changed. But there are multiple,
>correct, different sets of rules used to generate an
>exact image from the raw data.
I've been talking about the RAW file from the beginning. So too were
you at that time. Remember "Floyd, I suspect you have been smoking
something which is not good for you. Subject to statistical error
limitations, ... The data in the RAW file can't be restructured to
make a different image without changing the data."
>
>>>The sensor locations are hardly irrelevant either. As I
>>>said, at least *nine* of them are used to generate each
>>>pixel in the resulting image, and you can be assured the
>>>location is relevant! It isn't one pixel and then 8
>>>other randomly chosen locations... it's a group of 9
>>>(or more).
>>
>>So?
>
>So please cease this silliness where you claim the
>sensor locations are irrelevant.
For any one camera, its just one of the items which go to the
transformation of the image to the RAW file. The sensor locations are
invariant as is the other camera hardware, and the firmware for that
matter.
>
>>>>The signals generated by the sensors are determined by the
>>>>rules inherent in the camera's software.
>>>
>>>They are determined by rules inherent in the camera's
>>>hardware. The sensor is not manipulated by software
>>>other than clearing it and reading it. A given amount
>>>of light on one sensor locations produces *exactly* the
>>>same output from the sensor regardless of the camera's
>>>software.
>>
>>I should have said "The signals generated by the sensors are
>>-interpreted- by the rules inherent in the camera's software". To that
>>extent they are 'determined'.
>
>I quoted you exactly above. Now you want to change what
>you said.
Its called clarification. I haven't changed the meaning.
>
>Regardless, you are still wrong. The signals from the
>sensor are interpreted according to *hardware* and the
>resulting data set is written to a RAW file format.
>That is what is "interpreted" by software.
Have I ever said otherwise? But so what?
>
>>>>As I have already said, there
>>>>is a one to one correspondence between the source image and the RAW
>>>>file.
>>>
>>>You can say that all you like, but it still requires at
>>>least *nine* different sensor locations to generate data
>>>for each pixel of the resulting image. It is not a one
>>>to one relationship.
>>
>>I see the problem. You misunderstand what I mean by 'one to one'. By
>>that expression I mean that one imgage transforms into one RAW data
>>set. Its not as though the transformation entails (say) a quadratic
>>equation where the one image can give rise to either one of two RAW
>>data sets. See http://www.yourdictionary.com/one-to-one
>
>So you now admit that it is not software at all, but a
>hard wired hardware transform.
I don't see why you should suddenly try to make that point. In any
case, while I don't know about your camera, I can download an update
for mine. That doesn't sound as though it is all hardware to me.
>
>By next weekend we may force you into writing something
>that is clear enough to make some sense.
I assumed a certain level of technical competence from your
background.
>
>>>>You don't have a choice of RAW files for a given image. Nor do
>>>>you have a choice of images for a given RAW file.
>>>
>>>But you have a choice of an infinite number of resulting
>>>images when the camera raw data is interpolated. None
>>>of them are exactly the same as your "source image" that
>>>was projected onto the sensor.
>>
>>... and none of them are the image defined by the RAW data. Close,
>>maybe, but not exact.
>
>That is precisely what I've been trying to get through
>your head! Good. Now you can get on with a sane
>discusssion of raw data processing.
I wouldn't argue with you over what you have just said but I would
like to point out that this discussion has been about the interpolated
data saved in the RAW file.
>
>The raw data does not define one specific image. When
>the data is interpolated there is then an image!
And when that data is interpolated and saved in a RAW file then there
is only the one image. Run that RAW file backwards through the same
transformation and you end back up with the original image of which
there can only be the one.
Eric Stevens
nospam
<3606f3ff-3205-41f5...@s12g2000yqi.googlegroups.com>,
Poldie <Pol...@gmail.com> wrote:
> Odd? It's what I've been saying, over and over again.
it's not true for all raw files.
nospam
<fl...@apaflo.com> wrote:
> >the additional code is built into the operating system. absent some
> >user specified parameters, it will use predefined defaults. the app
> >can also specify whether it wants the jpeg or the raw, and can also
> >provide controls to tweak the image.
>
> Sure, the OS has a built in raw conversion program for the
> cameras that will be released next year with new formats...
i never said that it would support future formats.
> You just want it to be so great... that you'll claim *anything*,
> even if it is abjectly absurd.
i'm only stating what it can do.
> >> That conversion
> >> can (and probably would) create a distinctly different
> >> image than the embedded JPEG.
> >
> >yea and? neither one is a 100% exact rendition of the original scene.
> >maybe the jpeg is better, maybe it isn't. if it's that important,
> >write the app to display both and let the user decide.
>
> Exactly. It requires an application.
actually it doesn't require an application.
> An OS does *NOT* have
> raw conversion software built into it.
don't tell microsoft or apple.
Floyd L. Davidson
>On Sun, 31 May 2009 16:11:00 -0800, fl...@apaflo.com (Floyd L.
>Davidson) set out to change the substance of the discussion by
>massively editing the article to which he is responding. He is alos
>trying to switch the argument from the relationship of the original
>image to the RAW file to the relationship of the original image to the
>raw data (which is quite different from the content of the RAW file).
You actually are that dense!
>>Exactly. So why are you claiming otherwise? The raw
>>data set is not changed. But there are multiple,
>>correct, different sets of rules used to generate an
>>exact image from the raw data.
>
>I've been talking about the RAW file from the beginning. So too were
>you at that time. Remember "Floyd, I suspect you have been smoking
>something which is not good for you. Subject to statistical error
>limitations, ... The data in the RAW file can't be restructured to
>make a different image without changing the data."
The data in the raw file is not restructured.
Your nonsense is still nonsense.
>>>>The sensor locations are hardly irrelevant either. As I
>>>>said, at least *nine* of them are used to generate each
>>>>pixel in the resulting image, and you can be assured the
>>>>location is relevant! It isn't one pixel and then 8
>>>>other randomly chosen locations... it's a group of 9
>>>>(or more).
>>>
>>>So?
>>
>>So please cease this silliness where you claim the
>>sensor locations are irrelevant.
>
>For any one camera, its just one of the items which go to the
>transformation of the image to the RAW file. The sensor locations are
>invariant as is the other camera hardware, and the firmware for that
>matter.
So what are you trying to say? The sensor locations *are*
relevant!
You do understand that "firmware" is where the
"software" is, right?
I'm getting the idea that you have a list of buzz words; but no
idea what any of it means.
>>>>>The signals generated by the sensors are determined by the
>>>>>rules inherent in the camera's software.
That statement is blatantly false.
>>>>They are determined by rules inherent in the camera's
>>>>hardware. The sensor is not manipulated by software
>>>>other than clearing it and reading it. A given amount
>>>>of light on one sensor locations produces *exactly* the
>>>>same output from the sensor regardless of the camera's
>>>>software.
>>>
>>>I should have said "The signals generated by the sensors are
>>>-interpreted- by the rules inherent in the camera's software". To that
>>>extent they are 'determined'.
This statement is blatantly *different*.
>>I quoted you exactly above. Now you want to change what
>>you said.
>
>Its called clarification. I haven't changed the meaning.
They you don't understand what you said.
>>Regardless, you are still wrong. The signals from the
>>sensor are interpreted according to *hardware* and the
>>resulting data set is written to a RAW file format.
>>That is what is "interpreted" by software.
>
>Have I ever said otherwise? But so what?
You did say otherwise. Quoted above.
>>So you now admit that it is not software at all, but a
>>hard wired hardware transform.
>
>I don't see why you should suddenly try to make that point. In any
>case, while I don't know about your camera, I can download an update
>for mine. That doesn't sound as though it is all hardware to me.
You aren't going to download an update that changes how the
hardware processes sensor data to generate the "raw data". It's
hard wired. The sensor output is *analog*, and the digital
data is generated by a series of *hardware* devices. About all
the software does is switch the hardware on and off!
>I assumed a certain level of technical competence from your
>background.
That is correct. A few decades working with digital data,
transmission systems (which is what the hardware between the
sensor and the CF card is) and little things like that... :-)
>I wouldn't argue with you over what you have just said but I would
>like to point out that this discussion has been about the interpolated
>data saved in the RAW file.
The raw data saved in the RAW file is not interpolated.
>>The raw data does not define one specific image. When
>>the data is interpolated there is then an image!
>
>And when that data is interpolated and saved in a RAW file then there
That does not happen. (Except of course for the various
thumbnail JPEG images that are embedded in most RAW files.)
>is only the one image. Run that RAW file backwards through the same
>transformation and you end back up with the original image of which
>there can only be the one.
It is a one way process and it cannot be precisely
reversed. If for no other reason than what is called
quantization distortion... However, in addition to that
the JPEG image which results from interpolation simply
does not contain anything like the full amount of
information that was in the RAW file's data. You cannot
reverse the process.
Floyd L. Davidson
He didn't say that it was. What's your point?
Eric Stevens
Davidson) wrote:
>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>On Sun, 31 May 2009 16:11:00 -0800, fl...@apaflo.com (Floyd L.
>>Davidson) set out to change the substance of the discussion by
>>massively editing the article to which he is responding. He is alos
>>trying to switch the argument from the relationship of the original
>>image to the RAW file to the relationship of the original image to the
>>raw data (which is quite different from the content of the RAW file).
>
>You actually are that dense!
I read the words. I even quoted them down below. In fact, because you
have (surreptitiously) snipped an awful lot of what follows, its only
two paragraphs down.
>
>>>Exactly. So why are you claiming otherwise? The raw
>>>data set is not changed. But there are multiple,
>>>correct, different sets of rules used to generate an
>>>exact image from the raw data.
>>
>>I've been talking about the RAW file from the beginning. So too were
>>you at that time. Remember "Floyd, I suspect you have been smoking
>>something which is not good for you. Subject to statistical error
>>limitations, ... The data in the RAW file can't be restructured to
>>make a different image without changing the data."
>
>The data in the raw file is not restructured.
>
>Your nonsense is still nonsense.
How can you relate a different image in the camera to the one RAW
file?
>
>>>>>The sensor locations are hardly irrelevant either. As I
>>>>>said, at least *nine* of them are used to generate each
>>>>>pixel in the resulting image, and you can be assured the
>>>>>location is relevant! It isn't one pixel and then 8
>>>>>other randomly chosen locations... it's a group of 9
>>>>>(or more).
>>>>
>>>>So?
>>>
>>>So please cease this silliness where you claim the
>>>sensor locations are irrelevant.
>>
>>For any one camera, its just one of the items which go to the
>>transformation of the image to the RAW file. The sensor locations are
>>invariant as is the other camera hardware, and the firmware for that
>>matter.
>
>So what are you trying to say? The sensor locations *are*
>relevant!
Only as part of the transformation algorithm.
>
>You do understand that "firmware" is where the
>"software" is, right?
>
>I'm getting the idea that you have a list of buzz words; but no
>idea what any of it means.
One of us doesn't seem to.
>
>>>>>>The signals generated by the sensors are determined by the
>>>>>>rules inherent in the camera's software.
>
>That statement is blatantly false.
You made it false by chopping out the text around it which made clear
what I was talking about. For the benefit of others I had written:
"The sensor locations are irrelevant. The RAW data is derived
from the sensors by rules which are determined by the
manufacturer of the camera. The signals generated by the
sensors are determined by the rules inherent in the camera's
software. As I have already said, there is a one to one
correspondence between the source image and the RAW
file. You don't have a choice of RAW files for a given image.
Nor do you have a choice of images for a given RAW file".
>
>>>>>They are determined by rules inherent in the camera's
>>>>>hardware. The sensor is not manipulated by software
>>>>>other than clearing it and reading it. A given amount
>>>>>of light on one sensor locations produces *exactly* the
>>>>>same output from the sensor regardless of the camera's
>>>>>software.
>>>>
>>>>I should have said "The signals generated by the sensors are
>>>>-interpreted- by the rules inherent in the camera's software". To that
>>>>extent they are 'determined'.
>
>This statement is blatantly *different*.
>
>>>I quoted you exactly above. Now you want to change what
>>>you said.
>>
>>Its called clarification. I haven't changed the meaning.
>
>They you don't understand what you said.
I thought that was your problem. That's why I clarified it.
>
>>>Regardless, you are still wrong. The signals from the
>>>sensor are interpreted according to *hardware* and the
>>>resulting data set is written to a RAW file format.
>>>That is what is "interpreted" by software.
>>
>>Have I ever said otherwise? But so what?
>
>You did say otherwise. Quoted above.
I can't see where. Someone must have accidentally deleted it.
>
>>>So you now admit that it is not software at all, but a
>>>hard wired hardware transform.
>>
>>I don't see why you should suddenly try to make that point. In any
>>case, while I don't know about your camera, I can download an update
>>for mine. That doesn't sound as though it is all hardware to me.
>
>You aren't going to download an update that changes how the
>hardware processes sensor data to generate the "raw data". It's
>hard wired. The sensor output is *analog*, and the digital
>data is generated by a series of *hardware* devices. About all
>the software does is switch the hardware on and off!
First we are not talking about the RAW data. We (should) always have
been talking about the RAW data file. Second, in the case of the Nikon
D300 the update has changed the way in which the raw data from the
sensors have been interpreted and saved to the RAW file.
>
>>I assumed a certain level of technical competence from your
>>background.
>
>That is correct. A few decades working with digital data,
>transmission systems (which is what the hardware between the
>sensor and the CF card is) and little things like that... :-)
I thought you were a psychologist.
>
>>I wouldn't argue with you over what you have just said but I would
>>like to point out that this discussion has been about the interpolated
>>data saved in the RAW file.
>
>The raw data saved in the RAW file is not interpolated.
See the last line of ...
http://en.wikipedia.org/wiki/Bayer_filter
"Bryce Bayer's patent called the green photosensors
luminance-sensitive elements and the red and blue ones
chrominance-sensitive elements. He used twice as many
green elements as red or blue to mimic the human eye's
greater resolving power with green light. These elements
are referred to as sensor elements, sensels, pixel sensors,
or simply pixels; sample values sensed by them, after
interpolation, become image pixels."
>
>>>The raw data does not define one specific image. When
>>>the data is interpolated there is then an image!
>>
>>And when that data is interpolated and saved in a RAW file then there
>
>That does not happen. (Except of course for the various
>thumbnail JPEG images that are embedded in most RAW files.)
Umm...
>
>>is only the one image. Run that RAW file backwards through the same
>>transformation and you end back up with the original image of which
>>there can only be the one.
>
>It is a one way process and it cannot be precisely
>reversed. If for no other reason than what is called
>quantization distortion...
Don't come the technical heavy with me! After all, you are the one who
claimed to not understand what I meant by "statistical error
limitations".
>However, in addition to that
>the JPEG image which results from interpolation simply
>does not contain anything like the full amount of
>information that was in the RAW file's data. You cannot
>reverse the process.
HOW DO I MAKE IT CLEAR THAT FROM THE BEGINNING WE HAVE BEEN TALKING
ABOUT THE RELATIONSHIP BETWEEN THE ORIGINAL IMAGE ON THE SENSOR AND
THE 'RAW' FILE.
Sorry for shouting but I've said the above several times, I've quoted
from the original articls, and you still keep trying to switch to
conversion from RAW to JPG. That's an entirely different question.
Eric Stevens
Eric Stevens
wrote:
They already know. That's why they include RAW conversion software
with their OS.
Eric Stevens
Floyd L. Davidson
>>You actually are that dense!
>
>I read the words. I even quoted them down below. In fact, because you
>have (surreptitiously) snipped an awful lot of what follows, its only
>two paragraphs down.
You still think that I should quote your entire silly article.
That is *dense*.
>>So what are you trying to say? The sensor locations *are*
>>relevant!
>
>Only as part of the transformation algorithm.
No shit Sherlock. Which is to say, yes they are and
your statements otherwise were mistaken from the start.
>>You do understand that "firmware" is where the
>>"software" is, right?
>>
>>I'm getting the idea that you have a list of buzz words; but no
>>idea what any of it means.
>
>One of us doesn't seem to.
And it isn't at all difficult to determine which that
would be, Eric. Try, for example, to get a grip on
"interpolation" before you continue on with this
discussion. Try learning where software is used in the
data flow, and where it is a purely hardward process.
>You made it false by chopping out the text around it which made clear
>what I was talking about. For the benefit of others I had written:
>
> "The sensor locations are irrelevant. The RAW data is derived
> from the sensors by rules which are determined by the
> manufacturer of the camera. The signals generated by the
> sensors are determined by the rules inherent in the camera's
> software. As I have already said, there is a one to one
> correspondence between the source image and the RAW
> file. You don't have a choice of RAW files for a given image.
> Nor do you have a choice of images for a given RAW file".
Yes, and your statement is still false. Explaining a
false statement doesn't change the fact that it is
false.
False: "sensor locations are irrelevant"
False: "signals generated by the sensors are
determined by ... software"
False: "Nor do you have a choicce of images
for a given RAW file"
Nice paragraph.
>>>>Regardless, you are still wrong. The signals from the
>>>>sensor are interpreted according to *hardware* and the
>>>>resulting data set is written to a RAW file format.
>>>>That is what is "interpreted" by software.
>>>
>>>Have I ever said otherwise? But so what?
>>
>>You did say otherwise. Quoted above.
>
>I can't see where. Someone must have accidentally deleted it.
Now, if you missed where you'd said it before, take a look at
what you just repeated. See it now? It's wrong...
>>>>So you now admit that it is not software at all, but a
>>>>hard wired hardware transform.
>>>
>>>I don't see why you should suddenly try to make that point. In any
>>>case, while I don't know about your camera, I can download an update
>>>for mine. That doesn't sound as though it is all hardware to me.
>>
>>You aren't going to download an update that changes how the
>>hardware processes sensor data to generate the "raw data". It's
>>hard wired. The sensor output is *analog*, and the digital
>>data is generated by a series of *hardware* devices. About all
>>the software does is switch the hardware on and off!
>
>First we are not talking about the RAW data. We (should) always have
>been talking about the RAW data file.
The "RAW data file" is merely a file containing the
camera raw data. The only part of the file that relates
to the image is the data it contains. Which is to say
that we *are* talking about the "RAW data", even if you
want to call if a "RAW data file". It's the same data
either way.
Note that "sensor data", in the context of this
discussion, would be the analog data directly read from
the sensor (though in other contexts those words might
be used to mean the digital data too). "RAW data"
clearly must refer to the digital data that goes into
the "RAW file". That is the only place where "RAW" is
used. (And I often use "raw", simply because "RAW"
is grammatically incorrect. They are the same.)
>Second, in the case of the Nikon
>D300 the update has changed the way in which the raw data from the
>sensors have been interpreted and saved to the RAW file.
Nice try, but I just read the release notes for Nikon's
upgraded firmware for the D300, and saw exactly *nothing*
like what you are saying.
Provide details, and be specific.
>>>I wouldn't argue with you over what you have just said but I would
>>>like to point out that this discussion has been about the interpolated
>>>data saved in the RAW file.
>>
>>The raw data saved in the RAW file is not interpolated.
>
>See the last line of ...
>http://en.wikipedia.org/wiki/Bayer_filter
>
> "Bryce Bayer's patent called the green photosensors
> luminance-sensitive elements and the red and blue ones
> chrominance-sensitive elements. He used twice as many
> green elements as red or blue to mimic the human eye's
> greater resolving power with green light. These elements
> are referred to as sensor elements, sensels, pixel sensors,
> or simply pixels; sample values sensed by them, after
> interpolation, become image pixels."
Didn't you read what that paragraph says????
Are you unable to determine that the "after
interpolation" is refering not to generation of data
that goes into the RAW file, but rather what is done
with data *from* the RAW file in order to make an image
(such as TIFF or JPEG). That is what "image pixels" means.
The data saved in the RAW file has not yet been
interpolated, and when it is interpolated it is *not*
saved in the RAW file, and is no longer considered "raw"
data.
>>>>The raw data does not define one specific image. When
>>>>the data is interpolated there is then an image!
>>>
>>>And when that data is interpolated and saved in a RAW file then there
>>
>>That does not happen. (Except of course for the various
>>thumbnail JPEG images that are embedded in most RAW files.)
>
>Umm...
Ummmm..... see above.
>>>is only the one image. Run that RAW file backwards through the same
>>>transformation and you end back up with the original image of which
>>>there can only be the one.
>>
>>It is a one way process and it cannot be precisely
>>reversed. If for no other reason than what is called
>>quantization distortion...
>
>Don't come the technical heavy with me! After all, you are the one who
>claimed to not understand what I meant by "statistical error
>limitations".
I know exactly what *you* meant by that. The point was
that your statement was wrong, and you threw in
nonsensical statement to make it appear to have
significance. Statistical error limitations indeed!
>>However, in addition to that
>>the JPEG image which results from interpolation simply
>>does not contain anything like the full amount of
>>information that was in the RAW file's data. You cannot
>>reverse the process.
>
>HOW DO I MAKE IT CLEAR THAT FROM THE BEGINNING WE HAVE BEEN TALKING
>ABOUT THE RELATIONSHIP BETWEEN THE ORIGINAL IMAGE ON THE SENSOR AND
>THE 'RAW' FILE.
Then don't talk about interpolation and other software processing
of the raw data, all of which takes place on data *after* it is
placed in the RAW file.
>Sorry for shouting but I've said the above several times,
And then you talk about something different. You don't
seem to have even a meager knowledge of the data flow.
>I've quoted
>from the original articls, and you still keep trying to switch to
>conversion from RAW to JPG. That's an entirely different question.
Then stop talking about processing the RAW data to make an image.
Floyd L. Davidson
Exactly... it's application software "with" the OS, not
part of it. Except for strange definitions of "OS", which
granted both Microsoft and Apple General Counsel's have been
known to make a case for.
Chris H
<fl...@apaflo.com> writes
>Chris H <ch...@phaedsys.org> wrote:
>>>In fact, you cannot know of any Public Domain software
>>>that is copyrighted or requires a license to use.
>>
>>In FACT. I do. I have a whole CD of it. PD software was quite common 15
>>years ago. PD SW along with Shareware was often on the disks and CD's
>>with computer magazines.
>
>Look, get this one part of it straight: If it is PD it
>does not have copyright protection and can be used
>without any form of license at all.
>
>Shareware is copyrighted, and is not in the Public
>Domain.
Lets get one thing straight YOU have a definition of Public Domain that
is different to the SW industry I work in. We supply SW for a living.
Mike
>I still have difficulties dealing with the concept of RAW
>files. Someone suggested that RAW files are like negatives, while-as
>JPEG files are like prints.
>My question is whether we can physically see a RAW file... I mean
>without placing it in the mercy of a software to open it as a JPEG
you cannot see any digital photo file without using software and a
computer! However, programs like Photoshop can view RAW images as well
as JPEGs or TIFFs etc.
The difference between a RAW file and a JPEG is that the former is
unprocessed beyond basic camera functions, JPEGs are adjusted by lots
of camera ancilliary functions like white balance and quality
settings, JPEGs will normally contain less information than the
original RAW.
--
Mike
Floyd L. Davidson
>In message <87zlctk...@apaflo.com>, Floyd L. Davidson
><fl...@apaflo.com> writes
>>Chris H <ch...@phaedsys.org> wrote:
>>>>In fact, you cannot know of any Public Domain software
>>>>that is copyrighted or requires a license to use.
>>>
>>>In FACT. I do. I have a whole CD of it. PD software was quite common 15
>>>years ago. PD SW along with Shareware was often on the disks and CD's
>>>with computer magazines.
>>
>>Look, get this one part of it straight: If it is PD it
>>does not have copyright protection and can be used
>>without any form of license at all.
>>
>>Shareware is copyrighted, and is not in the Public
>>Domain.
>
>Lets get one thing straight YOU have a definition of Public Domain that
>is different to the SW industry I work in. We supply SW for a living.
Lets get one thing straight, the definition that I've
quoted is virtually the *only* definition in use. It is
clearly the correct definition for the UK legal system.
It is clearly correct for the US legal system. It is
clearly the definition used by the Berne Convention.
You are simply unaware of what the term means and have
made an assumption which is incorrect. You have not and
cannot demonstrate that *anyone* of significance uses
your definition. That is true because in fact any dictionary
that you look in will provide a virtually identical definition
to the one that I quoted.
Here it is again:
From The Collaborative International Dictionary of English v.0.48 [gcide]:
Public domain,
1. the territory belonging to a State or to the general
government; public lands. [U.S.]
2. the situation or status of intellectual property which is
not protected by copyright, patent or other restriction on
use. Anything
in the public domain may be used by anyone without
restriction. The effective term of force of copyrights and
patents are limited by statute, and after the term
expires, the writings and inventions thus protected go
into the public domain and are free for use by all.
From The Free On-line Dictionary of Computing (27 SEP 03):
public domain
(PD) The total absence of copyright protection. If
something is "in the public domain" then anyone can copy it or
use it in any way they wish. The author has none of the
exclusive rights which apply to a copyright work.
The phrase "public domain" is often used incorrectly to refer
to freeware or shareware (software which is copyrighted
but is distributed without (advance) payment). Public domain
means no copyright -- no exclusive rights. In fact the phrase
"public domain" has no legal status at all in the UK.
Even Wikipedia gets it right:
http://en.wikipedia.org/wiki/Public_domain#British_law
Here is a discussion and comparison of UK and US copyright
law, with a definition of Public Domain:
http://www.economicexpert.com/a/Public:domain.html
To put is mildly, your claims that Public Domain includes
software that is copyrighted or requires a license to use
is incorrect. *Nobody* *anywhere* uses your definition.
If you work for a company that produces software products,
I would *highly* suggest that you consult the companies
legal staff.
Eric Stevens
Davidson) wrote:
>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>>You actually are that dense!
>>
>>I read the words. I even quoted them down below. In fact, because you
>>have (surreptitiously) snipped an awful lot of what follows, its only
>>two paragraphs down.
>
>You still think that I should quote your entire silly article.
>That is *dense*.
Hell No! You should cut and paste my article to make it mean whatever
you would like it to mean. :-(
>
>>>So what are you trying to say? The sensor locations *are*
>>>relevant!
>>
>>Only as part of the transformation algorithm.
>
>No shit Sherlock. Which is to say, yes they are and
>your statements otherwise were mistaken from the start.
>
>>>You do understand that "firmware" is where the
>>>"software" is, right?
>>>
>>>I'm getting the idea that you have a list of buzz words; but no
>>>idea what any of it means.
>>
>>One of us doesn't seem to.
>
>And it isn't at all difficult to determine which that
>would be, Eric. Try, for example, to get a grip on
>"interpolation" before you continue on with this
>discussion. Try learning where software is used in the
>data flow, and where it is a purely hardward process.
YOU try looking up interpolation in the context of the Bayer process.
I've done it once already for you. It didn't seem to ring a bell, even
the first time.
>
>>You made it false by chopping out the text around it which made clear
>>what I was talking about. For the benefit of others I had written:
>>
>> "The sensor locations are irrelevant. The RAW data is derived
>> from the sensors by rules which are determined by the
>> manufacturer of the camera. The signals generated by the
>> sensors are determined by the rules inherent in the camera's
>> software. As I have already said, there is a one to one
>> correspondence between the source image and the RAW
>> file. You don't have a choice of RAW files for a given image.
>> Nor do you have a choice of images for a given RAW file".
>
>Yes, and your statement is still false. Explaining a
>false statement doesn't change the fact that it is
>false.
>
>False: "sensor locations are irrelevant"
>
>False: "signals generated by the sensors are
> determined by ... software"
>
>False: "Nor do you have a choicce of images
> for a given RAW file"
Look up Bayer interpolation.
Nope. What comes out of the sensor is not what is saved in the RAW
file. There is a transformation involved.
>
>Note that "sensor data", in the context of this
>discussion, would be the analog data directly read from
>the sensor ....
... what analog data?
> ...(though in other contexts those words might
>be used to mean the digital data too).
I see you have had second thoughts.
>"RAW data"
>clearly must refer to the digital data that goes into
>the "RAW file". That is the only place where "RAW" is
>used. (And I often use "raw", simply because "RAW"
>is grammatically incorrect. They are the same.)
>
>>Second, in the case of the Nikon
>>D300 the update has changed the way in which the raw data from the
>>sensors have been interpreted and saved to the RAW file.
>
>Nice try, but I just read the release notes for Nikon's
>upgraded firmware for the D300, and saw exactly *nothing*
>like what you are saying.
>
>Provide details, and be specific.
>
What do you make of:
. Image quality: NEF (RAW ) + JPEG
. NEF (RAW) recording: Lossless compressed or Compressed
. Image size: S or M
That sounds like a change in the way raw data from the sensors have
been interpreted and saved to the RAW file.
>>>>I wouldn't argue with you over what you have just said but I would
>>>>like to point out that this discussion has been about the interpolated
>>>>data saved in the RAW file.
>>>
>>>The raw data saved in the RAW file is not interpolated.
>>
>>See the last line of ...
>>http://en.wikipedia.org/wiki/Bayer_filter
>>
>> "Bryce Bayer's patent called the green photosensors
>> luminance-sensitive elements and the red and blue ones
>> chrominance-sensitive elements. He used twice as many
>> green elements as red or blue to mimic the human eye's
>> greater resolving power with green light. These elements
>> are referred to as sensor elements, sensels, pixel sensors,
>> or simply pixels; sample values sensed by them, after
>> interpolation, become image pixels."
>
>Didn't you read what that paragraph says????
>
>Are you unable to determine that the "after
>interpolation" is refering not to generation of data
>that goes into the RAW file, but rather what is done
>with data *from* the RAW file in order to make an image
>(such as TIFF or JPEG). That is what "image pixels" means.
Haw! You really don't understand what Bayer interpolation is all
about.
>
>The data saved in the RAW file has not yet been
>interpolated, ....
How else do you reckon it is derived from the Bayer mosaic?
> ... and when it is interpolated it is *not*
>saved in the RAW file, and is no longer considered "raw"
>data.
Well, at least you understand that much.
>
>>>>>The raw data does not define one specific image. When
>>>>>the data is interpolated there is then an image!
>>>>
>>>>And when that data is interpolated and saved in a RAW file then there
>>>
>>>That does not happen. (Except of course for the various
>>>thumbnail JPEG images that are embedded in most RAW files.)
>>
>>Umm...
>
>Ummmm..... see above.
>
>>>>is only the one image. Run that RAW file backwards through the same
>>>>transformation and you end back up with the original image of which
>>>>there can only be the one.
>>>
>>>It is a one way process and it cannot be precisely
>>>reversed. If for no other reason than what is called
>>>quantization distortion...
>>
>>Don't come the technical heavy with me! After all, you are the one who
>>claimed to not understand what I meant by "statistical error
>>limitations".
>
>I know exactly what *you* meant by that. The point was
>that your statement was wrong, and you threw in
>nonsensical statement to make it appear to have
>significance. Statistical error limitations indeed!
My oath there are statistical error limitations! That you call it
'quantization distortion' doesn't change the fact.
>
>>>However, in addition to that
>>>the JPEG image which results from interpolation simply
>>>does not contain anything like the full amount of
>>>information that was in the RAW file's data. You cannot
>>>reverse the process.
>>
>>HOW DO I MAKE IT CLEAR THAT FROM THE BEGINNING WE HAVE BEEN TALKING
>>ABOUT THE RELATIONSHIP BETWEEN THE ORIGINAL IMAGE ON THE SENSOR AND
>>THE 'RAW' FILE.
>
>Then don't talk about interpolation and other software processing
>of the raw data, all of which takes place on data *after* it is
>placed in the RAW file.
Dingbat - interpolation is an assential part of going from the Bayer
array to the RAW data file. Please don't continue to pretend
otherwise.
>
>>Sorry for shouting but I've said the above several times,
>
>And then you talk about something different. You don't
>seem to have even a meager knowledge of the data flow.
>
>>I've quoted
>>from the original articls, and you still keep trying to switch to
>>conversion from RAW to JPG. That's an entirely different question.
>
>Then stop talking about processing the RAW data to make an image.
I haven't been. If anything I've been talking about working backwards
from the RAW data file to reconstruct the original image.
Eric Stevens
Chris H
<fl...@apaflo.com> writes
>Chris H <ch...@phaedsys.org> wrote:
>>In message <87zlctk...@apaflo.com>, Floyd L. Davidson
>><fl...@apaflo.com> writes
>>>Chris H <ch...@phaedsys.org> wrote:
>>>>>In fact, you cannot know of any Public Domain software
>>>>>that is copyrighted or requires a license to use.
>>>>
>>>>In FACT. I do. I have a whole CD of it. PD software was quite common 15
>>>>years ago. PD SW along with Shareware was often on the disks and CD's
>>>>with computer magazines.
>>>
>>>Look, get this one part of it straight: If it is PD it
>>>does not have copyright protection and can be used
>>>without any form of license at all.
>>>
>>>Shareware is copyrighted, and is not in the Public
>>>Domain.
>>
>>Lets get one thing straight YOU have a definition of Public Domain that
>>is different to the SW industry I work in. We supply SW for a living.
>
>Lets get one thing straight, the definition that I've
>quoted is virtually the *only* definition in use.
It's not.
>It is
>clearly the correct definition for the UK legal system.
It isn't
>If you work for a company that produces software products,
>I would *highly* suggest that you consult the companies
>legal staff.
I have
Mike
>programs like Photoshop can view RAW images as well
>as JPEGs or TIFFs etc.
and PS also has a RAW preprocessor which I think duplicates the in
camera functions like white balance at the start of post processing in
a non destructive way, I find it a much better way to go although you
end up storing a lot more data, my raws are 17,000 KB each from a 14.6
MP camera.
(I know nothing about mosaics or interpolation :-) )
--
Mike
Floyd L. Davidson
Now now Chris, you have just passed to the stage of flat
falsification. You have *not* talked to a lawyer about
it. No point in lying about it.
And as demonstrated by the quotes/cites that I posted it
is rather clear that in fact it is UK law.
The fact that you have not (and cannot) find a single
authoritative source that gives any other definition
that the one that I've quoted (from several
authoritative sources) is indicative.
nospam
<eric.s...@sum.co.nz> wrote:
> >The "RAW data file" is merely a file containing the
> >camera raw data. The only part of the file that relates
> >to the image is the data it contains. Which is to say
> >that we *are* talking about the "RAW data", even if you
> >want to call if a "RAW data file". It's the same data
> >either way.
>
> Nope. What comes out of the sensor is not what is saved in the RAW
> file. There is a transformation involved.
what type of transformation and from what to what?
depending on the camera, there may be minor changes such as analog
white balance or noise reduction, but for all intents the data in the
raw file *is* the data off the sensor, at least with bayer sensors.
> >Note that "sensor data", in the context of this
> >discussion, would be the analog data directly read from
> >the sensor ....
>
> ... what analog data?
from the sensor, before the a/d converter.
> >>Second, in the case of the Nikon
> >>D300 the update has changed the way in which the raw data from the
> >>sensors have been interpreted and saved to the RAW file.
> >
> >Nice try, but I just read the release notes for Nikon's
> >upgraded firmware for the D300, and saw exactly *nothing*
> >like what you are saying.
> >
> >Provide details, and be specific.
> >
> What do you make of:
>
> . Image quality: NEF (RAW ) + JPEG
> . NEF (RAW) recording: Lossless compressed or Compressed
> . Image size: S or M
>
> That sounds like a change in the way raw data from the sensors have
> been interpreted and saved to the RAW file.
no it doesn't. the first is embedding the jpeg in addition to the raw
data and the second is how it's compressed. the third is for the size
of the jpeg file. raw files are always full size, with canon's sraw
being an exception (and since this is a nikon d300, not applicable).
> >>>>I wouldn't argue with you over what you have just said but I would
> >>>>like to point out that this discussion has been about the interpolated
> >>>>data saved in the RAW file.
> >>>
> >>>The raw data saved in the RAW file is not interpolated.
> >>
> >>See the last line of ...
> >>http://en.wikipedia.org/wiki/Bayer_filter
> >>
> >> "Bryce Bayer's patent called the green photosensors
> >> luminance-sensitive elements and the red and blue ones
> >> chrominance-sensitive elements. He used twice as many
> >> green elements as red or blue to mimic the human eye's
> >> greater resolving power with green light. These elements
> >> are referred to as sensor elements, sensels, pixel sensors,
> >> or simply pixels; sample values sensed by them, after
> >> interpolation, become image pixels."
> >
> >Didn't you read what that paragraph says????
> >
> >Are you unable to determine that the "after
> >interpolation" is refering not to generation of data
> >that goes into the RAW file, but rather what is done
> >with data *from* the RAW file in order to make an image
> >(such as TIFF or JPEG). That is what "image pixels" means.
>
> Haw! You really don't understand what Bayer interpolation is all
> about.
if anyone doesn't understand it, it's you. nowhere in what *you*
quoted says the data in the raw *file* is interpolated.
the interpolation is done in the raw converter on the computer, long
after the raw file has been created.
> >The data saved in the RAW file has not yet been
> >interpolated, ....
>
> How else do you reckon it is derived from the Bayer mosaic?
the data in the raw file is *before* the interpolation is done to
demosaic the image.
> > ... and when it is interpolated it is *not*
> >saved in the RAW file, and is no longer considered "raw"
> >data.
>
> Well, at least you understand that much.
odd, because that contradicts what you've been saying.
> >>>However, in addition to that
> >>>the JPEG image which results from interpolation simply
> >>>does not contain anything like the full amount of
> >>>information that was in the RAW file's data. You cannot
> >>>reverse the process.
> >>
> >>HOW DO I MAKE IT CLEAR THAT FROM THE BEGINNING WE HAVE BEEN TALKING
> >>ABOUT THE RELATIONSHIP BETWEEN THE ORIGINAL IMAGE ON THE SENSOR AND
> >>THE 'RAW' FILE.
> >
> >Then don't talk about interpolation and other software processing
> >of the raw data, all of which takes place on data *after* it is
> >placed in the RAW file.
>
> Dingbat - interpolation is an assential part of going from the Bayer
> array to the RAW data file. Please don't continue to pretend
> otherwise.
no need to pretend otherwise since that's totally incorrect.
> >>I've quoted
> >>from the original articls, and you still keep trying to switch to
> >>conversion from RAW to JPG. That's an entirely different question.
> >
> >Then stop talking about processing the RAW data to make an image.
>
> I haven't been. If anything I've been talking about working backwards
> from the RAW data file to reconstruct the original image.
that doesn't make any sense.
nospam
<fl...@apaflo.com> wrote:
> >>> An OS does *NOT* have
> >>> raw conversion software built into it.
> >>
> >>don't tell microsoft or apple.
> >
> >They already know. That's why they include RAW conversion software
> >with their OS.
>
> Exactly... it's application software "with" the OS, not
> part of it.
wrong. the raw conversion is part of the os itself and the 'software'
that uses it does not necessarily have to be in the form of an
application either. things have come a long way from a simple fopen()
call.
> Except for strange definitions of "OS", which
> granted both Microsoft and Apple General Counsel's have been
> known to make a case for.
uh, ok.
Savageduck
> On Mon, 01 Jun 2009 09:43:33 +0100, "Mike" <rub...@live.com> wrote:
>
>> programs like Photoshop can view RAW images
Not quite.
as well
>> as JPEGs or TIFFs etc.
>
> and PS also has a RAW preprocessor
No.
What PS or CS4 uses is ACR or Adobe Camera Raw, that is the software
which opens the RAW file, and is used to make RAW adjustments. You then
have the option to open the adjusted file or a copy of the adjusted file
in CS4. Once open in CS4 you can only make Photoshop adjustments RAW
adjustment are no longer an option once you have moved beyond ACR.
nospam
<savageduck1@{REMOVESPAM}me.com> wrote:
> What PS or CS4 uses is ACR or Adobe Camera Raw, that is the software
> which opens the RAW file, and is used to make RAW adjustments. You then
> have the option to open the adjusted file or a copy of the adjusted file
> in CS4. Once open in CS4 you can only make Photoshop adjustments RAW
> adjustment are no longer an option once you have moved beyond ACR.
not entirely true. you can optionally go back to camera raw and further
adjust the image without losing what was done in photoshop. or, switch
to lightroom where the same raw adjustments are applied.
Mike
<savageduck1@{REMOVESPAM}me.com> wrote:
>>> programs like Photoshop can view RAW images
>
>Not quite.
I was determined to carry on till someone corrected me:-)
>as well
>>> as JPEGs or TIFFs etc.
>>
>> and PS also has a RAW preprocessor
>No.
isn't Camera Raw PS4s "RAW preprocessor"?
>What PS or CS4 uses is ACR or Adobe Camera Raw, that is the software
>which opens the RAW file, and is used to make RAW adjustments.
Well, it comes with CS4, OK I could have said the Bridge+Camera Raw+
CS4 bundle, but at least now I know somebody cares :-)
(and it's not part of the operating system)
>> (I know nothing about mosaics or interpolation :-) )
haruph, nobody challenged that bit!
--
Mike
nospam
<rub...@live.com> wrote:
> >> and PS also has a RAW preprocessor
>
> >No.
>
> isn't Camera Raw PS4s "RAW preprocessor"?
it is.
Mike
>>> (I know nothing about mosaics or interpolation :-) )
>
>haruph, nobody challenged that bit!
What's really important about photography this week is why is Pentax
new range leader superceding K10 and then K20 called the "K7"?
--
Mike
Floyd L. Davidson
>On Sun, 31 May 2009 23:44:15 -0800, fl...@apaflo.com (Floyd L.
>Davidson) wrote:
>
>>Eric Stevens <eric.s...@sum.co.nz> wrote:
>>>>You actually are that dense!
>>>
>>>I read the words. I even quoted them down below. In fact, because you
>>>have (surreptitiously) snipped an awful lot of what follows, its only
>>>two paragraphs down.
>>
>>You still think that I should quote your entire silly article.
>>That is *dense*.
>
>Hell No! You should cut and paste my article to make it mean whatever
>you would like it to mean. :-(
I have not changed a single character of the silly
things you've written, and in no way have I ever changed
the meaning of a single sentence. Please do not blame
me for what you write!
Again though, it's time that you learned that proper
Usenet netiquette is to trim the quoted text to only that
require for context. I do that. You don't.
>>And it isn't at all difficult to determine which that
>>would be, Eric. Try, for example, to get a grip on
>>"interpolation" before you continue on with this
>>discussion. Try learning where software is used in the
>>data flow, and where it is a purely hardward process.
>
>YOU try looking up interpolation in the context of the Bayer process.
>I've done it once already for you. It didn't seem to ring a bell, even
>the first time.
Such as where you quoted Wikipedia, and didn't
understand what it said! As noted just 5 or so lines
above, learn something about the data flow.
>>>You made it false by chopping out the text around it which made clear
>>>what I was talking about. For the benefit of others I had written:
>>>
>>> "The sensor locations are irrelevant. The RAW data is derived
>>> from the sensors by rules which are determined by the
>>> manufacturer of the camera. The signals generated by the
>>> sensors are determined by the rules inherent in the camera's
>>> software. As I have already said, there is a one to one
>>> correspondence between the source image and the RAW
>>> file. You don't have a choice of RAW files for a given image.
>>> Nor do you have a choice of images for a given RAW file".
>>
>>Yes, and your statement is still false. Explaining a
>>false statement doesn't change the fact that it is
>>false.
>>
>>False: "sensor locations are irrelevant"
>>
>>False: "signals generated by the sensors are
>> determined by ... software"
>>
>>False: "Nor do you have a choicce of images
>> for a given RAW file"
>
>Look up Bayer interpolation.
And you'll find: 1) that sensor locations are relevant; 2) that
the signals generated by the sensors are not determined by
software, as that is a purely hardware domain; 3) that
the RAW file is data which has not been interpolated, and
when it is interpolated there are many choices for a given
set of raw data.
Note that interpolation is not what generates the data
in a "RAW file", it is what generates a TIFF or JPEG
formatted image file. Remember that you wanted to only
talk about RAW data, not the JPEG... but here you are
once again discussing the processing of data to produce
an image file...
Hmmm... right here it is:
>>>First we are not talking about the RAW data. We (should) always have
>>>been talking about the RAW data file.
>>
>>The "RAW data file" is merely a file containing the
>>camera raw data. The only part of the file that relates
>>to the image is the data it contains. Which is to say
>>that we *are* talking about the "RAW data", even if you
>>want to call if a "RAW data file". It's the same data
>>either way.
>
>Nope. What comes out of the sensor is not what is saved in the RAW
>file. There is a transformation involved.
That is a hardware transformation, not one that is
called interpolation and not one that is done with
software.
>>Note that "sensor data", in the context of this
>>discussion, would be the analog data directly read from
>>the sensor ....
>
>... what analog data?
The sensor is an analog device.
>> ...(though in other contexts those words might
>>be used to mean the digital data too).
>
>I see you have had second thoughts.
Neither of us has used it in that context, and since you
have repeatedly confused various parts of the data flow
it is absolutely essential to differentiate the analog
sensor data from the digital data output of the ADC.
In many contexts the sensor, the ISO amplifiers, and the
ADC are all considered "the sensor" in order to simplify
a discussion that really does not involve them other than
as a unit. This is clearly not one of those discussions.
>>"RAW data"
>>clearly must refer to the digital data that goes into
>>the "RAW file". That is the only place where "RAW" is
>>used. (And I often use "raw", simply because "RAW"
>>is grammatically incorrect. They are the same.)
>>
>>>Second, in the case of the Nikon
>>>D300 the update has changed the way in which the raw data from the
>>>sensors have been interpreted and saved to the RAW file.
>>
>>Nice try, but I just read the release notes for Nikon's
>>upgraded firmware for the D300, and saw exactly *nothing*
>>like what you are saying.
>>
>>Provide details, and be specific.
>>
>What do you make of:
>
> . Image quality: NEF (RAW ) + JPEG
> . NEF (RAW) recording: Lossless compressed or Compressed
> . Image size: S or M
>
>That sounds like a change in the way raw data from the sensors have
>been interpreted and saved to the RAW file.
It looks like the specifications from the User Manual to
me. Where's the change?
Granted though that they *could* upgrade the firmware
with a different RAW file data format. I can see how
*you* would call that a change in the data, but in fact
it isn't. It is a change in the way the data is
represented and stored in the file, but the *value* of
the data remains the same. Which is to say that the
data values which a raw converter will use for
interpolation will not be different. That processing
is merely encoding of values, not a form of processing
that affects the data or the images that are eventually
produced.
>>>>The raw data saved in the RAW file is not interpolated.
>>>
>>>See the last line of ...
>>>http://en.wikipedia.org/wiki/Bayer_filter
>>>
>>> "Bryce Bayer's patent called the green photosensors
>>> luminance-sensitive elements and the red and blue ones
>>> chrominance-sensitive elements. He used twice as many
>>> green elements as red or blue to mimic the human eye's
>>> greater resolving power with green light. These elements
>>> are referred to as sensor elements, sensels, pixel sensors,
>>> or simply pixels; sample values sensed by them, after
>>> interpolation, become image pixels."
>>
>>Didn't you read what that paragraph says????
>>
>>Are you unable to determine that the "after
>>interpolation" is refering not to generation of data
>>that goes into the RAW file, but rather what is done
>>with data *from* the RAW file in order to make an image
>>(such as TIFF or JPEG). That is what "image pixels" means.
>
>Haw! You really don't understand what Bayer interpolation is all
>about.
Haw! You have clearly misread the text you quoted!
Hilarious again!
The RAW data file does not contain data that has been
interpolated (de-mosaiced).
>>The data saved in the RAW file has not yet been
>>interpolated, ....
>
>How else do you reckon it is derived from the Bayer mosaic?
The raw data in the RAW file is derived using a rather
standard Analog-to-Digital Converter. Between the
sensor and the ADC there are analog amplifiers with
programmable gain, which are used to set the ISO
sensitivity.
The RAW file contains data that has not yet been
de-mosaiced. That is a software process that is used to
generate an image format, such as JPEG. (Remember that?
The process you didn't want to be discussed?)
>> ... and when it is interpolated it is *not*
>>saved in the RAW file, and is no longer considered "raw"
>>data.
>
>Well, at least you understand that much.
But you don't, and go on to claim that it is:
>Dingbat - interpolation is an assential part of going from the Bayer
>array to the RAW data file. Please don't continue to pretend
>otherwise.
You don't have a clue. Interpolation has *nothing* to
do with going from the Bayer array to the RAW data file.
It has to do with going from the raw data to an image
format, which as noted above is *no* *longer* *called* *raw*
*data*. It's usually either a TIFF or a JPEG data set.
That is *not* the data in a RAW data file.
>>Then stop talking about processing the RAW data to make an image.
>
>I haven't been. If anything I've been talking about working backwards
>from the RAW data file to reconstruct the original image.
Every time you mention "interpolation" or hint at the
de-mosaic process you are talking about processing the
RAW data to make an image. It is *never* a
reconstruction of the original image, because that
simply does not happen.
Mike
wrote:
>> isn't Camera Raw PS4s "RAW preprocessor"?
>
>it is.
Huh! I may be emboldened into saying something about mosaics at this
rate.
I reckon the The spectral transmittance of the CFA thingy along with
the demosaicing algothingy in the cameras operating system jointly
determine the color rendition
--
Mike
Chris H
<Hu...@nowhere.much.invalid> writes
>On 2009-06-01, Floyd L. Davidson <fl...@apaflo.com> wrote:
>
>> And as demonstrated by the quotes/cites that I posted it
>> is rather clear that in fact it is UK law.
>
>
>*plonk*
Thanks I was starting to think I was in the twilight zone and the many
SW companies we deal with had all got it wrong.
Chris H
Apparently not.
But I am actually selling SE at the moment and do not have time for your
fantasy world of mss using facts.
Floyd L. Davidson
>On 2009-06-01, Floyd L. Davidson <fl...@apaflo.com> wrote:
>
>> is rather clear that in fact it is UK law.
>
>
>*plonk*
If you could show otherwise... you would have.
Chris H
<Hu...@nowhere.much.invalid> writes
>On 2009-06-01, nospam <nos...@nospam.invalid> wrote:
>> In article <877hzwj...@apaflo.com>, Floyd L. Davidson
>><fl...@apaflo.com> wrote:
>>
>>> >>> An OS does *NOT* have
>>> >>> raw conversion software built into it.
>>> >>
>>> >>don't tell microsoft or apple.
>>> >
>>> >They already know. That's why they include RAW conversion software
>>> >with their OS.
>>>
>>> Exactly... it's application software "with" the OS, not
>>> part of it.
>>
>> wrong. the raw conversion is part of the os itself
>
>they're talking about?
In Floyds case when it comes to SW, yes.
There is no OS I am aware of where RAW conversion is an integral part of
the OS.
Many OS have separate utilities which interface to 3rd party Sw that is
also not part of the OS that can convert RAW files.
Floyd L. Davidson
Chris, it is clear that you cannot produce even a shred
of evidence to support what you've said. I've provided
multiple authoritative cites.
Be stubborn if you wish, but there isn't much doubt about
what the actual definition of Public Domain is. That puts
*you* in fantasy land.
Floyd L. Davidson
>In message <78hooiF...@mid.individual.net>, Huge
><Hu...@nowhere.much.invalid> writes
>>On 2009-06-01, Floyd L. Davidson <fl...@apaflo.com> wrote:
>>
>>> And as demonstrated by the quotes/cites that I posted it
>>> is rather clear that in fact it is UK law.
>>
>>Wrong.
>>
>>*plonk*
>
>Thanks I was starting to think I was in the twilight zone and the many
>SW companies we deal with had all got it wrong.
If there are so many of them, why is it that neither of you
can produce a shred of evidence?
nospam
<ch...@phaedsys.org> wrote:
> There is no OS I am aware of where RAW conversion is an integral part of
> the OS.
mac os x.
> Many OS have separate utilities which interface to 3rd party Sw that is
> also not part of the OS that can convert RAW files.
it's not a separate utility.
More yawns ...
>On 2009-06-01, nospam <nos...@nospam.invalid> wrote:
>> In article <877hzwj...@apaflo.com>, Floyd L. Davidson
>><fl...@apaflo.com> wrote:
>>
>>> >>> An OS does *NOT* have
>>> >>> raw conversion software built into it.
>>> >>
>>> >>don't tell microsoft or apple.
>>> >
>>> >They already know. That's why they include RAW conversion software
>>> >with their OS.
>>>
>>> Exactly... it's application software "with" the OS, not
>>> part of it.
>>
>> wrong. the raw conversion is part of the os itself
>
>Jesus. Are these groups *completely* full of people who have no idea what
>they're talking about?
No, just the uneducated idiots that psychotically believe in their
fictional jesus. Three centuries from now the same kind of people will be
worshipping Clark Kent, known as Kentians and celebrating his birth on a
day chosen to usurp another group's holiday, calling it Kentmas. At least
he actually accomplished something in those stories and there's real video
evidence of him doing so. Accomplishing more than that silly fictional
"jesus" character ever did, that's for damn sure. What a lame god they
invented. Couldn't even do as much as Super Man.
Chris H
<nos...@nospam.invalid> writes
Do explain
so Mac contains the RAW conversion
where do I find it on OSX1.4?
Bob Larter
> I am sorry if this topic may have been discussed too many times.
> However, I still have difficulties dealing with the concept of RAW
> files. Someone suggested that RAW files are like negatives, while-as
> JPEG files are like prints.
That's a pretty good way of putting it.
> My question is whether we can physically see a RAW file...
Huh? In what sense? That's kind of like asking if you can 'see' a Word file.
> I mean
> without placing it in the mercy of a software to open it as a JPEG
> file (and in the mean time, the software is doing the processing and
> converting it into JPEG using their own algorithm to produce what they
> consider to be the best JPEG.
Not 'best'. Just according to the default settings you have configured
in the camera. If you want 'best' you have to process it by hand.
I agree that perhaps people should
> create both RAW and JPEG files when they take pictures.
I certainly do, although I rarely use the in-camera JPEG file.
> The next question is whether commercial photo processing softwares
> (Photoshop, Paintshop, Aperture, etc) treating RAW files produced from
> different brand cameras differently, as I noticed that the extension
> file name for RAW files differ from cameras to cameras. Can the
> special software made by the camera's manufacturer (which sometimes
> comes with the camera that you purchase) do a better job than the
> commercially photo processing softwares?
That's a matter of debate. Some people prefer the results they get from
the makers RAW processing software, some prefer what they get from 3rd
party converters. Me, I prefer 3rd party (Photoshop ACR or RawShooter),
but that's my personal preference.
> I recall that someone mentioned that the camera's processing engine is
> not as versatile as a computer's photo processing software, as well as
> the time to produce the JPEG file in the camera is relatively short.
> Therefore, built-in camera processing engine cannot make a better job
> than a real photo processing software.
Correct. A camera has to produce a JPEG in a fraction on a second,
whereas software on your PC has the luxury of a more powerful processor,
more memory, & it can take as long as it needs to do the job properly.
> As processing speed is getting
> faster and faster, could a camera sometime in the future produces JPEG
> photos which are as good as or better than the commercial photo
> softwares?
It's a matter of physics & economics. Processor power on a big,
mains-powered PC with a ton of RAM is always going to be better than
that available on a small, battery-powered device.
--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
Bob Larter
> On May 31, 11:30 am, nospam <nos...@nospam.invalid> wrote:
>> In article
>>
>> Poldie <Pol...@gmail.com> wrote:
>>> RAW isn't a standard - different companies store data in different
>>> ways. The canon CR2 format (which has been reverse engineered and is
>>> just a google away if you're interested in the technical details) is,
>>> for the most part, a JPEG with compression disabled,
>> it's essentially a tiff, not a jpeg
>
> No, where I saw `for the most part` I'm referring to majority of the
> data in the CR2 file - that which makes up the detail of the image (as
> opposed to header into, thumbnail, colour tables etc). To the extent
> that I understand an analysis of this foramt, it's essentially a
> lossless JPEG.
If you're going to strip it down to that level, 0 compression JPEG & LZW
TIFF are basically the same thing.
Bob Larter
>> There **is** public domain software for Canon dSLRs, in DCRAW.exe.
>> You can get source code and look at it for yourself.
> >
>> ... CLIP ...
>>
>> Caveat: the dcraw code is dense. I have no 100% veridird what it does
>> by looking at the code. Don't attack me on this point
>> unless you have successfully understood the dcraw code which is
>> executed using -D or -d.
>
> I also downloaded the dcraw software a few months ago and looked it over
> briefly, couldn't make sense of the code in short order so I have up on
> it. It was just a curiosity to me so it didn't matter much. I hate how
> some code can be so hard to read. Some programmers truly have a gift
> there :) And those that can read it are somewhat blessed.
<grin> Reading other peoples' C code is defintely more of an art than a
science. Hell, reading your own C code can be tricky at times.
Bob Larter
> In message <87iqjip...@apaflo.com>, Floyd L. Davidson
> <fl...@apaflo.com> writes
>> "mcdonaldREMOVE TO ACTUALLY REACH ME"@scs.uiuc.edu wrote:
>>> The answer is, at least for Canon, yes. There is public
>>> domain software available that will convert the data, which is
>>> intensity data at each pixel, into a pixel-for-pixel file, that is,
>>> 8 or 12 or 14 bits per pixel. This is not full color, it
>>> is filtered by the Bayer filter.
>>>
>>> You can then take that file and make a 24 bit file from it, by
>>> moving red pixel values to the red byte, blue ones to the
>>> blue byte, and green ones to the green byte, leaving the other
>>> two bytes of each 24 bit number zero. This can then
>>> be displayed on you computer. To get the color right you need to scale the
>>> R, G, and B numbers correctly. It will display as
>>> a color image, albeit rather dark since each pixel will
>>> be mostly black.
>>>
>>> I've done it, it works.
>>>
>>> Doug McDonald
>> Most of the responses to the OP's questions are more or
>> less correct. This one is different, as virtually nothing
>> said above is correct. (Not even the comment about
>> software for Canon, as no it is not Public Domain at all.)
>
> I think we have a confusion over terminology
>
> RAW files are the RAW sensor data with a meta file and usually an
> embedded Jpg for viewing.
Correct. With the raw sensor data losslessly compressed via some flavour
of the LZW algorithm, & one or more JPEGs embedded in their own fields,
& the whole kit & kaboodle packed into a TIFF format file.
> As pointed out the actual format of the RAW files depends on the
> sensors etc and is normally specific to a manufacturer or a range of its
> cameras.
Correct, although they're all based on well known formats, such as TIFF.
(And TIFF is an insanely complex format, with as many variants as there
are software houses or camera manufacturers...)
> The information on the formats is not Open Source or Public Domain
Correct.
> but
> the source and or libraries and or formats ARE freely available.
Pretty much, but only because a lot of people have put in serious work
reverse-engineering the details.
> I have
> the information and software for the Ninkon Raw format.
Including the encrypted fields?
> However whilst it is free to download, just as with GNU, Open Source and
> any other software there is a licence.
Sorry, not correct. Unless perhaps you mean applying to become an
official developer, & signing a non-disclosure agreement. Otherwise,
you're confusing the reverse-engineered doc's/code with the official SDK
documentation.
> This is why there are many programs under many licences and costs that
> will handle RAW files from most manufacturers.
This more because of the effort some very generous people have put into
reverse-engineering the various RAW formats.
> With the RAW data you can apply the settings that were in the camera
> when the picture was taken or change them. This gives you the
> opportunity to "re-take" the photo on the computer +/- 3 stops
> (depending on your RAW processor) Some such as DxO can even adjust for
> lens characteristics.
Correct.
> So you can from a RAW file produce a series of jpegs with different F
> stops
F-Stops, not so much, although you can certainly change the effective EV.
> and white balance settings as though you were still where you took
> the picture with the camera.
Correct.
> As such it is more versatile than a conventional negative
Indeed. Which is why I only shoot RAW.
> If you process the RAW file and turn out a TIFF which is loss less that
> TIFF is more like a film negative. Than you can apply "dark room "
> techniques on the TIFF to produce prints in Photoshop which is the
> equivalent of a darkroom.
<nods> In that sense, RAW is even better than a film negative, because
you can't change the WB on a piece of film.
> The RAW processor is a NEW step in digital photography that gives more
> flexibility
Indeed.
Bob Larter
> Thanks for the overwhelming replies. I appreciate this very much. I
> also like the analogy of building a house vs. renovate the house.
> Perhaps in the future I will try to keep both RAW and JPEG files,
> particularly when taking photos for important events.
>
> I do, however, wonder that by working on raw format, one will end up
> spending much more time post processing after the photos are taken.
This is often the case, yes.
> This sometimes I do not have the luxury to do it.
In that case, you might be better off to stick with JPEGs.
I shoot under very difficult lighting conditions, so I pretty much have
to shoot RAW to get good images. If you're shooting under good lighting
you might well not need to go to that much trouble. The single biggest
reason to shoot RAW is if you can't get a good white-balance under your
usual lighting conditions. If you're happy with the colour you get from
the automatic white-balance, you will probably be perfectly happy with
the results you get from shooting JPEGS with AWB switched on.
> Therefore, I also
> look around with interest on what camera is doing better than the
> others (in terms of generating JPEG photos), or at least the
> processing that this particular camera is suit to your likings in
> colour, contrast, tones, etc.
>
> I just have one question - if you take a photo which was out of focus,
> could you actually make it in focus when you have the raw files?
No. Not a chance. If the focus is out, RAW won't help you.
> One more time, I thank you very much to all responders for the very
> useful discussion on this topic!
I'm glad we could help.
tony cooper
<savageduck1@{REMOVESPAM}me.com> wrote:
>Mike wrote:
>> On Mon, 01 Jun 2009 09:43:33 +0100, "Mike" <rub...@live.com> wrote:
>>
>>> programs like Photoshop can view RAW images
>
>Not quite.
>
>as well
>>> as JPEGs or TIFFs etc.
>>
>> and PS also has a RAW preprocessor
>
>
>No.
>
>What PS or CS4 uses is ACR or Adobe Camera Raw, that is the software
>which opens the RAW file, and is used to make RAW adjustments. You then
>have the option to open the adjusted file or a copy of the adjusted file
>in CS4. Once open in CS4 you can only make Photoshop adjustments RAW
>adjustment are no longer an option once you have moved beyond ACR.
>
You can't make additional adjustments to the RAW image *in PS* once
you've opened that image in PS, but the RAW image remains. You can
always re-open it, make changes, and then re-open it in PS.
I download in Bridge and convert the image to a .dng file, edit, open
in PS, and save-as a .psd, .tiff, or .jpg. No matter what I do in
CS4, the .dng file is still there in case I want to start over.
I'm taking an advanced class in Photoshop on restoration, so I took
advantage of being a student and got Lightroom. I'm still reading
Kelby's book on Lightroom, so I'm sticking with Bridge until I'm
comfortable with Lightroom. So far, all I've done is use it for
keywording.
--
Tony Cooper - Orlando, Florida
Bob Larter
> On Sat, 30 May 2009 21:32:27 -0800, fl...@apaflo.com (Floyd L.
> Davidson) wrote:
>
> Floyd has failed to point out that at this point he has omitted a
> great deal of previous text. I know he has been around more than long
> enough to know that this is not the right thing to do.
>
>> Eric Stevens <eric.s...@sum.co.nz> wrote:
>>> Floyd, I suspect you have been smoking something which is not good for
>>> you. Subject to statistical error limitations, there is a one to one
>>> correspondence between the source image and the RAW file. One can be
>>> converted to the other using the rules inherent in the camera's
>>> software.
>> What do you mean by "the source image"?
>
> That which is projected onto the sensor by the lens.
That's what's encoded in the RAW file. It's a losslessly compressed dump
of the contents of the image sensor, without any interpretation.
[...]
> file. You don't have a choice of RAW files for a given image. Nor do
> you have a choice of images for a given RAW file.
>> Did you read, and understand, the following few paragraphs?
>>
>>>> A JPEG or TIFF file contains an image. The RAW file
>>>> contains data to make an image.
>>>>
>>>> For example, each "sensal" location on the sensor does
>>>> *not* translate to a single pixel in the resulting
>>>> image. Instead the data from at least 9 different
>>>> sensors locations is used to determine the Red, Green,
>>>> and Blue values for a single pixel.
He's talking about the *process* of converting from the RAW image to the
RGB image that you see on your screen, which includes Bayer
deconvolution. As he says, there is no 1:1 relationship between a pixel
("sensel") on the image sensor & a pixel on the RGB image that you see
on your screen.
Bob Larter
> On Sun, 31 May 2009 16:11:00 -0800, fl...@apaflo.com (Floyd L.
[...]
> I've been talking about the RAW file from the beginning. So too were
> you at that time. Remember "Floyd, I suspect you have been smoking
> something which is not good for you. Subject to statistical error
> make a different image without changing the data."
This is incorrect. As Floyd has said, the same RAW data can result in an
infinite number of final images. For example, one can process it with a
huge range of WB values, or change the EV correction by plus or minus a
couple of stops, set the black level to anything you like, etc, etc.
None of these changes require changes to the RAW data, merely the
interpretation of it.