Is VLC 3.0.3 for Windows 7?

In article , Mayayana
wrote:


| BMP is
| uncompressed and Windows-specific. So up into the
|
| (So basically a RAW format.)
|
RAW refers to any one of a number of proprietary
formats that conserve data recorded by the camera.
It holds much more data than the standard file formats.

more accurately, raw is the data directly from the sensor, before it's
converted into an image (de-bayering + other processing).

Those formats (PNG, GIF, JPG, TIF) are just different
kinds of packages for a BMP. They all decompress
to bitmaps -- rectangular grids of numeric pixel values.

png, gif, jpg and tif are entirely different formats than bmp.

I find RAW fascinating to work with because one can
draw so much out. For instance, if the image is
underexposed it can be brightened to bring out the
colors in the image. With a bitmap you can't do that.
If you brighten it you just make each pixel lighter.
Each point in the image is already a fixed color value.

of course you can do that with a bitmap, but the results will be
nowhere near as good as with raw.

So with RAW you can pick the best image available
from the data before reducing it to a bitmap.

that's because raw is 'undeveloped'.

In message , Mayayana
writes:
"J. P. Gilliver (John)" wrote

| BMP is
| uncompressed and Windows-specific. So up into the
|
| (So basically a RAW format.)
|
RAW refers to any one of a number of proprietary
formats that conserve data recorded by the camera.

(You said above that BMP is also a proprietary format - well, you said
it's Windows-specific, but that's more or less the same as proprietary.)

It holds much more data than the standard file formats.
Those formats (PNG, GIF, JPG, TIF) are just different
kinds of packages for a BMP. They all decompress
to bitmaps -- rectangular grids of numeric pixel values.

I find RAW fascinating to work with because one can
draw so much out. For instance, if the image is
underexposed it can be brightened to bring out the
colors in the image. With a bitmap you can't do that.

I do not see how RAW is not what you are calling a bitmap. It might have
more bits per pixel, but if it's coming from a pixel sensor, it's a
bitmap. (And AFAIK no digital camera uses other than a pixel sensor - in
fact I can't think what other sort there could be, if we're talking
digital rather than film.)

If you brighten it you just make each pixel lighter.
Each point in the image is already a fixed color value.

I can't see how it isn't in RAW, either. You can apply gamma-like curves
- different for each of the three colours, if you wish - to do clever
things with colours near either end of the histogram. But this applies
whether RAW or bitmap (since RAW is a bitmap).

[Also - does it stand for something? If not, I'd call it raw, rather
than RAW. Meaning raw (uncompressed) data.]

So with RAW you can pick the best image available
from the data before reducing it to a bitmap.

IT IS A BITMAP! Unless it's a very fancy camera that has taken several
images (bitmaps) at different exposures (and in extremis focuses). So
it's either a bitmap, or a collection of bitmaps - nothing magical.
[]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Tact is the ability to describe others as they see themselves. -Abraham
Lincoln, 16th president of the U.S (1809-1865)

I presume it became so when memory cards were very small, and had become
established when they became bigger - or, the problem never went away
because "megapixel envy" means sensor size _in pixels_ kept growing
(roughly keeping pace with card capacity). [My favourite camera has a
3.2 MP sensor - and I usually have it set to 1.]

Back in the Dark Ages we had one of the first Kodak digital cameras that
used a 3.5" diskette as the storage medium. You had a choice of saving the
image as RAW or JPG, but not and. If one chose JPG then two files were
generated, one with the actual image and one with the exposure data. I
forget what the resolution was, and it took a significant time to process
and store the image. Its burst mode was three frames only. Still, it was
nice for snapshots and being able to have the images available right away
as opposed to film. We did still shoot 35mm with my trusty Pentax, and
Walmart had the option to both have prints made and have the negative
scanned so you could download it.

In article , Tim
wrote:

Back in the Dark Ages we had one of the first Kodak digital cameras that
used a 3.5" diskette as the storage medium.

that would have been a sony mavica.

https://3.img-dpreview.com/files/p/E...1323663/mavica
71b.png

In article , J. P. Gilliver (John)
wrote:


It holds much more data than the standard file formats.
Those formats (PNG, GIF, JPG, TIF) are just different
kinds of packages for a BMP. They all decompress
to bitmaps -- rectangular grids of numeric pixel values.

I find RAW fascinating to work with because one can
draw so much out. For instance, if the image is
underexposed it can be brightened to bring out the
colors in the image. With a bitmap you can't do that.

I do not see how RAW is not what you are calling a bitmap. It might have
more bits per pixel, but if it's coming from a pixel sensor, it's a
bitmap. (And AFAIK no digital camera uses other than a pixel sensor - in
fact I can't think what other sort there could be, if we're talking
digital rather than film.)

raw is not a bitmap. in fact, raw is not an image at all until it's
processed into one. each 'pixel' (actually a sensel) is not an rgb
triplet, but rather only one component (ignoring foveon which is even
more of a mess to process).

at a minimum, raw needs to be de-bayered to convert it into rgb and may
also need lens adjustments and other processing.




[Also - does it stand for something? If not, I'd call it raw, rather
than RAW. Meaning raw (uncompressed) data.]

raw is not an acronym, but it's capitalized for some reason.

J. P. Gilliver (John) wrote:


I do not see how RAW is not what you are calling a bitmap. It might have
more bits per pixel, but if it's coming from a pixel sensor, it's a
bitmap. (And AFAIK no digital camera uses other than a pixel sensor - in
fact I can't think what other sort there could be, if we're talking
digital rather than film.)

You might want to find an article on RAW
and see if it describes the orientation of the
data. It's possible the layout is a Bayer pattern
matching the sensor itself.

https://en.wikipedia.org/wiki/Bayer_filter

https://www.adobe.com/digitalimag/pd...rawcapture.pdf

Paul

In article , Paul
wrote:

I do not see how RAW is not what you are calling a bitmap. It might have
more bits per pixel, but if it's coming from a pixel sensor, it's a
bitmap. (And AFAIK no digital camera uses other than a pixel sensor - in
fact I can't think what other sort there could be, if we're talking
digital rather than film.)

You might want to find an article on RAW
and see if it describes the orientation of the
data.

orientation is a tag in the data, not part of the format, and requires
an orientation sensor in the camera, which just about all digital
cameras do. old digital cameras (and possibly disposables) might not.

It's possible the layout is a Bayer pattern
matching the sensor itself.

that's not only possible, but pretty much guaranteed, as just about
every digital camera uses a bayer sensor.

In article , Wolf K
wrote:

because the software used to view it ignores the orientation tag. in
other words, it's buggy.

False.

nope.

"J. P. Gilliver (John)" wrote

| (You said above that BMP is also a proprietary format - well, you said
| it's Windows-specific, but that's more or less the same as proprietary.)
|
I wouldn't call it proprietary. It's the basic storage format
for pixel data. A BMP only has a few bytes of header, describing
the size, color depth, etc. The rest is just the map. A grid
of pixel values. So, for instance, if the first 3 pixels in the
upper left of a 24-bit bitmap are red then the bytes will start
with FF 00 00 FF 00 00 FF 00 00 (Each pixel being represented
by bytes for RGB.) And you can know the file size. It's the
header plus 3 bytes per pixel. So the bytes representing a
24-bit image 10x10 would be 10 x 10 x 3, or 300.

Except for the header, it's just numeric pixel values in a
long string.

Stop me if you already know all this.....
The bitmap is the basic storage method of the data for
display onscreen. Those 3 red pixels have to be painted
to the screen. They're painted by telling Windows the bytes
that make up the rows of the image pixels. Whether the 3 red
pixels are in a PNG, JPG, or whatever, that format has to
be unpacked to get a device independent bitmap (the pixel
bytes) to paint onscreen.

I imagine Mac and Linux must have something similar
because it's the most basic form of the image data. They
have to deal in bitmaps just llike Windows does, if they
want to display or print images. But I don't know what
their equivalent is. They could do something like store
the bytes in reverse order -- 00 00 FF rather than
FF 00 00 -- but it would still be a record of pixel values
nonetheless. There's no image as such in JPG bytes.

|
| I do not see how RAW is not what you are calling a bitmap. It might have
| more bits per pixel, but if it's coming from a pixel sensor, it's a
| bitmap. (And AFAIK no digital camera uses other than a pixel sensor - in
| fact I can't think what other sort there could be, if we're talking
| digital rather than film.)
|

You may know more about it than I do. I don't
really understand how the camera sensor works.
And some camera sensors may actually record in
RGB. But even if they do, it's more image data than
a 24-bit RGB pixel value, and it's stored using a
company's own method, related to the functioning
of the sensor hardware. It can only be edited using
software designed to deal with that particular
RAW format.
A bitmap is the currency of digital images for
display or printing. Whatever the sensor has recorded,
it has to be reduced to get the bitmap pixel bytes.

Some of the descriptions compare RAW to a
negative, which has all the recorded image data
and then can be used to print the data as desired,
changing the resulting photo by exposing the
paper for more or less time and leaving it in the
developing bath for more or less time. That doesn't
seem like a good analogy to me, but maybe it's as
close as it can get. The resulting photo is a little
like a bitmap in the sense that each point of color
in the photo has been locked into a single hue. I
guess the big difference would be that the photo
resolution is much higher than a typical pixel image.

| If you brighten it you just make each pixel lighter.
| Each point in the image is already a fixed color value.
|
| I can't see how it isn't in RAW, either. You can apply gamma-like curves
| - different for each of the three colours, if you wish - to do clever
| things with colours near either end of the histogram. But this applies
| whether RAW or bitmap (since RAW is a bitmap).
|
An example that I find useful: The first time I
tried taking a RAW image it was of a cyclamen in
a dimly lit room. The picture was mostly just shades
of gray. With a RAW editor I was able to pull out the
green leaves and magenta blossoms, as though I
had added a light to the scene after the fact. If
that camera shot had been a JPG then it would
have just been a bitmap.... and a poor one at that.
The shades of gray would have been all I had to
work with. A grid of grayish dots. If the magenta
showed as a slightly pinkish gray then I could saturate
that with red. But that color wouldn't be in the image.
I'd be painting it on.

| [Also - does it stand for something? If not, I'd call it raw, rather
| than RAW. Meaning raw (uncompressed) data.]

Yes. I think it's just called RAW to denote a file
format. The file extension can be different, but
RAW indicates one of those raw image formats.
.... I don't think there's any rule about it. I'm
sure you can call it "raw" if you want to.

|
| IT IS A BITMAP! Unless it's a very fancy camera that has taken several
| images (bitmaps) at different exposures (and in extremis focuses). So
| it's either a bitmap, or a collection of bitmaps - nothing magical.

See above. It's not a bitmap and it's not a series
of bitmaps. But I don't have the technical know-how
to say exactly what the difference is. I only know that
a bitmap stores color values for pixels while a RAW file
stores much more data. It's magical to me, because
I know the frustration of trying to coax a decent image
out of limited data.

In message , Mayayana
writes:

"J. P. Gilliver (John)" wrote

| (You said above that BMP is also a proprietary format - well, you said
| it's Windows-specific, but that's more or less the same as proprietary.)
|
I wouldn't call it proprietary. It's the basic storage format
for pixel data. A BMP only has a few bytes of header, describing
the size, color depth, etc. The rest is just the map. A grid
of pixel values. So, for instance, if the first 3 pixels in the
upper left of a 24-bit bitmap are red then the bytes will start
with FF 00 00 FF 00 00 FF 00 00 (Each pixel being represented
by bytes for RGB.) And you can know the file size. It's the
header plus 3 bytes per pixel. So the bytes representing a
24-bit image 10x10 would be 10 x 10 x 3, or 300.

Except for the header, it's just numeric pixel values in a
long string.

Stop me if you already know all this.....

Stop (-:
[]
| I do not see how RAW is not what you are calling a bitmap. It might have
| more bits per pixel, but if it's coming from a pixel sensor, it's a
[]
You may know more about it than I do. I don't
really understand how the camera sensor works.
And some camera sensors may actually record in
RGB. But even if they do, it's more image data than
a 24-bit RGB pixel value, and it's stored using a
[]
Having read the two articles that Paul pointed us at, it seems that the
situation is somewhere between what the two of us thought. Apparently
most sensors are RGB, but have twice as many G sensors, arranged thus:

RGRGRGRG
GBGBGBGB
RGRGRGRG RG
GBGBGBGB or in other words, made up of GB quartets. (Some apparently now
use different filters, such as CMY.) They also - as I'd already said -
in general store more than 8 bits per element.

So it's still a bitmap, but the green at least has more resolution.
(Similar to the habit in some video circuitry - reflecting the response
of the human eye - of "luminance on green".)

How you convert this into normal RGB - which you have to do to actually
_use_ it; after all, the R and G parts have only the resolution of the
quartets - involves assorted compromises, in particular to avoid edge
effects. The two articles Paul found do a good job explaining (I found
the second one easier to follow, though I _think_ both included all the
information).
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

A sleekzorp without a tornpee is like a quop without a fertsneet (sort of).

In article , J. P. Gilliver (John)
wrote:

| I do not see how RAW is not what you are calling a bitmap. It might have
| more bits per pixel, but if it's coming from a pixel sensor, it's a
[]
You may know more about it than I do. I don't
really understand how the camera sensor works.
And some camera sensors may actually record in
RGB. But even if they do, it's more image data than
a 24-bit RGB pixel value, and it's stored using a
[]
Having read the two articles that Paul pointed us at, it seems that the
situation is somewhere between what the two of us thought. Apparently
most sensors are RGB,

none are rgb. even foveon sensors, which falsely claims to be rgb, are
not.

but have twice as many G sensors, arranged thus:

RGRGRGRG
GBGBGBGB
RGRGRGRG RG
GBGBGBGB or in other words, made up of GB quartets. (Some apparently now
use different filters, such as CMY.)

otherwise known as a bayer pattern, and cmyg hasn't been used in a long
time.

They also - as I'd already said -
in general store more than 8 bits per element.

the sensor is an analog device and doesn't store bits.

it generates an analog voltage proportional to the light hitting it,
which is then quantized by the adc, from 8 to 16 bits per component.
the more bits in the adc, the wider the dynamic range of the image.

So it's still a bitmap, but the green at least has more resolution.
(Similar to the habit in some video circuitry - reflecting the response
of the human eye - of "luminance on green".)

it's not a bitmap, nor does it work the way you think it does (no
quartets).

How you convert this into normal RGB - which you have to do to actually
_use_ it; after all, the R and G parts have only the resolution of the
quartets

myth.

bayer does *not* work by quartets, which would look like ****.

bayer processing is *far* more complex, with spatial resolution only
slightly less than a monochrome sensor.

- involves assorted compromises, in particular to avoid edge
effects.

everything involves compromises.

The two articles Paul found do a good job explaining (I found
the second one easier to follow, though I _think_ both included all the
information).

they were very basic and did not cover the wide variety of bayer
algorithms.

"Frank Slootweg" wrote in message
news
NY wrote:
"Frank Slootweg" wrote in message
news
I don't know if all cameras and phones get it right, but our cameras
[1] do get it right. They do not only sense the orientation of the
camera, but also the movement. So I can turn the camera 90 degrees
clockwise or 90 degrees counter-clockwise and it will detect correct
portrait mode in both cases. (I've not been so silly to hold it
upside-down for landscape, but it will probably get that right as
well.)

My problem is that whereas there is an obvious right way up for the phone
in
portrait mode (with the phone name at the bottom and the writing the
correct
way up!), there's no right and wrong way once you rotate the phone into
landscape. I can never remember which way is right (no rotation needed)
and
which is wrong (180 degree rotation needed). Inevitable if I've taken
various photos, some will be one way and some will be the other. It would
be
easier if the screen showed some text that did not rotate so it was
always
the correct way up, so I'd be consistent.

Sorry, but I don't get your problem. AFAICT, it's the same situation
as the upside-down real camera. I just checked on my smartphone and as I
expected, it also gets this right. I.e. for both speaker-right/
microphone-left and speaker-left/microphone-right, a landscape picture
has the correct orientation, i.e. 'ground' at the bottom, 'sky' at the
top. That is, because - as I mentioned - the device doesn't only sense
orientation, but also movement. Perhaps you can fool it by quick or/and
akward movements, but in normal use they haven't failed me.

I was meaning that unless you have viewer/player software that honours EXIF
rotation flags for stills and video, you need to rotate it manually. And you
need any editing software to preserve the flags when saving a modified copy
or else perform the rotation to the correct orientation.

I've just taken a couple of photos with my Samsung camera held in portrait
and landscape, and the loaded them into various image-editing packages. And
most *do* honour the flag. My mistake. I'm wondering if I never tried it
because the photos were displayed wrongly in Windows Explorer so I *assumed*
(not a good idea) than all programs would display them that way.

Paint Shop Pro 5 is the only one which does not honour the flag.

PSPX (V10.01), PSP X8, Photoshop Elements 7 and Photoshop Elements 11 all
rotate photos correctly, even though in some cases the preview
image-selection dialog box may display them wrongly - that dialog box may be
produced by Windows rather than the application.

The same is true of photo taken with my Canon SX260 compact camera and my
Nikon D90 SLR.

I've learned something new today. Thank you!


I have noticed a "funny". In PSP X8 the Image Information for the images
which are open (and displayed correctly) both say Orientation=Landscape" in
the EXIF Information tab, and both give the image size as 2848x4288,
irrespective of whether the image is portrait or landscape.

Photoshop Elements 11, File | File Info | Camera Data doesn't explicitly
mention the Orientation flag. Again the width and height are the same for
both orientations, not exchanged for portrait versus landscape.

"Phil Hobbs" wrote in message
...
But why can't we use a bigger film then? Should we always compare 135
film against CMOS sensors of different size?


A bit of possibly useful discussion:

https://electrooptical.net/News/photographic-film/

One other factor to bear in mind: the depth of field varies with lens focal
length, not field of view of the subject. This means that if you take a
photo on 120 film and on 35 mm, with appropriate focal lengths of the two
lenses to give the same field of view of the subject in both cases, and use
the same aperture, the DOF will be less on the 120 photo than the 35 mm
photo. So if 80 mm gives a certain field of view on 120 and 50 mm gives the
same field of view (ie shows the same extent of the subject) on 50 mm, and
both lenses are at f 4 (and so both will use the same shutter speed for the
same speed of film), the 120 photo will have a shallower DOF. That is why it
is so difficult to get shallow DOF on a compact or phone camera, because the
lens is such a short focal length to suit the very small sensor, that almost
everything is in focus even at a wide aperture (and the lens might have more
artifacts and aberrations than the comparable lens that gives the same field
of view for a 35 mm camera). In all this, I'm talking about the field of
view of the *subject* - ie how much of the subject (wide/telephoto) is
included within the frame of film or the sensor.

This is why some drama TV programmes are shot on 16 mm or with a similar
size CMOS sensor, but with a 35 mm-format movie camera lens and an
intermediate ground-glass screen. This allows a shallower DOF to be achieved
for artistic reasons without having to open up the (16 mm format) lens to a
wider aperture which might show more lens flaws. The lens for 35 mm format
produces an image on the ground-glass screen that has a certain field of
view and depth of field which would be recorded on 35 mm film. The 16 mm
camera focuses that image (which is all at one plane) onto 16 mm film.

I wish I could find a URL that describes it, but I'm obviously not feeding
Google with the correct search keywords - a common problem I have.

"J. P. Gilliver (John)" wrote

| So it's still a bitmap, but the green at least has more resolution.
| (Similar to the habit in some video circuitry - reflecting the response
| of the human eye - of "luminance on green".)
|
| How you convert this into normal RGB - which you have to do to actually
| _use_ it; after all, the R and G parts have only the resolution of the
| quartets - involves assorted compromises, in particular to avoid edge
| effects.

I still don't really understand that. It sounds like
you have experience with optics. I understand what
a bitmap is and how it works. Even after reading
articles I can't explain the actual mechanics of
RAW image storage.

Whether to call that a bitmap is, I suppose, a
matter of terminology. I guess "bitmap" is actually
outdated, since it's really a byte-based pixel map.

But bitmap is a standard term in Windows
programming. It's not just any image data. It's
specifically defined and is specifically not JPG, TIF,
GIF, or RAW file data.
The string or array of file bytes defining pixels from
2 colors to 24-bit color is the only thing normally
referred to as a bitmap. It's central to computer
raster graphics functionality. And there's good reason
for that: A bitmap in that definition is the way that
digital images can be worked with/printed/displayed.
The other forms -- various file formats -- are storage
vehicles for that bitmap data.
Whether you want to see it onscreen or edit it,
you're always dealing with that string of bytes
that represent a grid of color points. The rest is
packaging. And in that sense, RAW is a different
animal. It's not a package for an RGB bitmap that
can be displayed onscreen or edited with standard
computer graphics software.

I think that's an important concept to understand
in order to understand how other image formats fit
in. Not understanding it accounts for much of the
reason that even photographers are often attached
to JPG. They don't understand the image format
landscape or what an image is in terms of digital
computing.

I used to sometimes get into debates
about this in a photo group. One of the photographers
was very talented, but a strong Mac partisan and
not so experienced with computers. He insisted that
bitmaps were outdated and a Windows invention,
simply because Macs don't have BMP files. He thought
I was "obsessed" with bitmaps. I couldn't
get it across to him that a JPG holds a bitmap. He
thought of it as a more modern, more
sophisticated, kind of image.

"Mayayana" wrote in message
news
I used to sometimes get into debates
about this in a photo group. One of the photographers
was very talented, but a strong Mac partisan and
not so experienced with computers. He insisted that
bitmaps were outdated and a Windows invention,
simply because Macs don't have BMP files. He thought
I was "obsessed" with bitmaps. I couldn't
get it across to him that a JPG holds a bitmap. He
thought of it as a more modern, more
sophisticated, kind of image.

I'd say that "bitmap" is synonymous with "raster": ie as distinct from
vector. It is a generic term for an image that is made up of a rectangular
grid of pixels, each with a certain brightness (or RGB triad of
brightnesses).

Windows rather hijacked that meaning by inventing a non-compressed file
format which consists of exactly width x height samples (eg at 8 or 24 bits
depth) with no run-length or JPEG compression. Sun had a very similar format
called RAS (raster) which is totally uncompressed. I hadn't realised that
Macs didn't have an equivalent, though I imagine it would be very easy for
an app to have a module that could read/write .bmp or .ras files if
required. Does it have any bitmap/raster file format that is lossless,
either by being uncompressed or else using a lossless compression algorithm.