Thirsty Moth

On Thu, 23 Jul 2015 01:06:08 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

There is the small matter of a huge wad of LR in the way.

lightroom is not in the way.

It's in the path which the image has to follow on it's way from the
raw form to the printer's native language.

are you going to start arguing about the path the electrons take in the
wires? or the emf if it's wireless? there's a conversion to tcp/ip
protocols, and 802.11n if it's over wifi. why not argue about *that*
conversion??

the answer is because *none* of it matters.

again, open a raw file, click print and collect the print. trivial.

In the same way that when you order a pizza on line you click
'pepperoni' and it turns up at your door without anyone making the
base, applying the topping, baking it in the oven or carrying it into
a vehicle so that it can be delivered.

You open the menu, click on an order and collect the pizza at the
door.

No doubt you think that none of the intermediate actions matter. In
fact they don't exist.
--

Regards,

Eric Stevens

In article ,
Whisky-dave wrote:

That makes sense. I just didn't realize RAW stored
EXIF. Since it's generally in JPGs I mistakenly thought
it was a JPG-only feature.

Nope it's a RAW feature which rubs off on JPEGs whenever they play with
the big boys.

I don;t like the term 'rub off here', but if you can use it so can I and from
what I've known, EXIF data did not come from RAW it rubbed off from TIFF
files originally.

if a user shoots raw, it absolutely came from raw.

https://en.wikipedia.org/wiki/Exchan...ge_file_format
Technical
The Exif tag structure is borrowed from TIFF files.

so is raw.

The standard only allows TIFF or JPEG files -- there is no provision for a
"raw" file type which would be a direct data dump from the sensor device.
This has caused camera manufacturers to invent many proprietary, incompatible
"raw" file formats. To solve this problem, Adobe developed the DNG format (a
TIFF-based raw file format), in hopes that manufacturers would standardize on
a single, raw file format.

and this is why not all RAW files are the same which is why converters are
needed. But really we should be using the word converter, the word usually
used for data is decode and encode. ;-P

raw files aren't the same because the sensors aren't the same.

if the sensor is different, the raw file *must* be different.

dng tries to address that but it doesn't support non-standard sensors
very well or at all.

In article ,
Whisky-dave wrote:

Opens a raw image in what?

any image editing app. it's entirely your choice.

what if your image editing app won't open that RAW file.

then choose another one. duh.

In article , Mayayana
wrote:

| | Why BMP?
| |
|
| It's a simple map of pixels with no lossiness, so
| if I'm through with RAW adjustments, or if I want
| to work on a JPG, BMP is a way to store the data.
| (On Windows.)
|
| it's a microsoft format that's not widely supported.

Spoken like a true Apple fan.

it has nothing to do with apple, despite your feeble attempt to turn it
into apple-bashing.

BMP is supported on all Microsoft OSs.

that's what i said.

I only use
Windows.

your loss.

windows won't be around forever.

mobile devices are already outselling windows and that's only going to
increase.

And BMP is the most basic, brass tacks
record of pixels in an image. In the typical 24-bit usage,
aside from a tiny header recording things like width and
height, it's just a record of 3-byte color values. No
special techniques or patented methods are required
to read/alter/render a BMP. It's merely the pixels that
all other formats are once they're displayed onscreen.

so what? it's still a microsoft format that's not widely supported.

it's also grossly inefficient.

So I use BMP *because* it's so widely supported.

except that it's not.

(I don't have any Apple products...never will...

your loss.

and have
no intention of emailing BMP files to anyone -- they're
too big for that.)

that's because it's an inefficient format and not all email apps
support embedded bmp images.

Any graphic Windows software
knows how to deal with BMPs and always will. The
Windows graphics API is based on BMPs.

one reason why windows is so behind the curve.

I expect the
Apple API is probably based on the same basic thing
with a different name.

mac/ios is a lot more advanced than a simple bitmap.

And I expect Macs probably
also have software that can handle BMPs, to convert
them to the Apple version.

macs and ios devices use an abstract image class that is independent of
the underlying format. an app opens an image file and the system does
the rest (somewhat simplified), including raw images from cameras as
well as the usual tiff, jpg, bmp, png, pdf, etc.

In article , Eric Stevens
wrote:

It has to be converted somewhere along the line
somewhere.

which is entirely internal to the computer, where all sorts of stuff
goes on, none of which matters to the user.

are you going to argue about conversions to tcp/ip or 802.11n to send
it to the printer?

If I was going to argue (which I really don't want to) I would say
sending a raw file from a camera to be translated by LR/PS/etc before
being sent on to the printer in the printer's native language can't be
considered as a printer printing directly from raw.

*all* files are translated to the printer's native language. why single
out raw?

if you print a jpeg, a spreadsheet, a text file or a 3d cad drawing,
they are all translated to whatever the printer expects.

users don't care about that ****.

a user opens a file, whether it's a raw image, a jpeg image, a
spreadsheet, or whatever else, they click print and collect the print
moments later.

In article , Tony Cooper
wrote:

are you going to argue about conversions to tcp/ip or 802.11n to send
it to the printer?

If I was going to argue (which I really don't want to) I would say
sending a raw file from a camera to be translated by LR/PS/etc before
being sent on to the printer in the printer's native language can't be
considered as a printer printing directly from raw.

If you take that position, then the printer also translates a .jpg
file to it's native language so it isn't printing directly from .jpg.

The printer is treating the RAW and .jpg file the same. You tell it
to print it, and it will.

exactly.

In article , Eric Stevens
wrote:

... and no option to print. Maybe you can do it on your Mac but no
Windows machine that I have seen has the ability to print straight
from a raw file. Presumably your OS has some kind of software which
Windows lacks.

Eric, back off! I just did print from a RAW file...on a PC with
Windows 7. I printed a .dng using LR, PS, and FastStone.

Tony. Please have another look. What you have done is not printing
directly from a raw file to a printer. You have sent the image through
a whole chain of software to convert the raw file into a form
acceptable to the printer.

it's exactly what he did.

he has a raw image, he clicked print and it printed.

Not only are you good at ignoring the bits in the middle, you even
deny that they exist.

i'm not ignoring anything and what exists or doesn't exist internal to
the computer makes absolutely no difference to the user.

In article , Eric Stevens
wrote:

Tony. Please have another look. What you have done is not printing
directly from a raw file to a printer. You have sent the image through
a whole chain of software to convert the raw file into a form
acceptable to the printer.

Perhaps I was not clear. There was no chain of software. I opened a
RAW files (.dng) in each of the three three programs listed above - at
separate times - clicked print, and printed each time from the RAW
file using a very basic Epson printer. Three prints.

Check it out. Download FastStone viewer (it's free) and view a RAW
file and then print the image. It's not just Adobe software that
handles printing from RAW. No Nikon program was used, either.

Windows 7 on a PC.

Well, LR, PS or Faststone are all software and you are not able to
print that image without using one of them (or similar).

you can't do anything with a computer without software.

In article , Eric Stevens
wrote:

There is the small matter of a huge wad of LR in the way.

lightroom is not in the way.

It's in the path which the image has to follow on it's way from the
raw form to the printer's native language.

are you going to start arguing about the path the electrons take in the
wires? or the emf if it's wireless? there's a conversion to tcp/ip
protocols, and 802.11n if it's over wifi. why not argue about *that*
conversion??

the answer is because *none* of it matters.

again, open a raw file, click print and collect the print. trivial.

In the same way that when you order a pizza on line you click
'pepperoni' and it turns up at your door without anyone making the
base, applying the topping, baking it in the oven or carrying it into
a vehicle so that it can be delivered.

You open the menu, click on an order and collect the pizza at the
door.

No doubt you think that none of the intermediate actions matter. In
fact they don't exist.

they don't.

what matters is how long it takes to get said pizza and if it tastes
good.

| windows won't be around forever.
| mobile devices are already outselling windows and that's only going to
| increase.
|
So... I should convert my BMPs to JPGs, buy
an iPhone, install a PS app on it, and henceforth
edit images only under a microscope while riding
on public transit or while trying to do something
else entirely. What a wonderfully futuristic idea.

| I expect the
| Apple API is probably based on the same basic thing
| with a different name.
|
| mac/ios is a lot more advanced than a simple bitmap.
|

Then Apple must have progressed beyond monitors.
Monitors display pixels in horizontal and vertical rows.
A bitmap is exactly that -- a map of those rows. When
you decode a JPG, GIF, etc for display it gets
decompressed into a bitmap. That's what's really
inside most image formats. RAW is different, and extra
data can be stored in some formats, but most image
types are just different ways to manage/store/transport
bitmaps.

| And I expect Macs probably
| also have software that can handle BMPs, to convert
| them to the Apple version.
|
| macs and ios devices use an abstract image class that is independent of
| the underlying format. an app opens an image file and the system does
| the rest (somewhat simplified)

Sounds like a bitmap, unless of course your
Mac displays the image as text rather than a
pixel pattern. If the programmer wants to tell
"the system" to brighten, sharpen, resize, or
whatever else, those are mathematical operations
performed on pixel grids -- a bitmap.