User ID

Wasnt following past pg 3 but now noticed its now 650 posts and 43 pages so Im skipping the huuuuuuuge middle and just reading only the last few pages just to see how incredibly stoooooopid things can get.

IOW, thanks for the laffs, clown car. I know youll all keep on keeping on. Ill check back much later and Im expecting the best !

DirtFarmer Loc: Escaped from the NYC area, back to MA

You're welcome. Hot discussions are always a source of interest to webbies as well as increasing traffic on UHH to raise the interest of advertisers.

User ID

(Download)

DirtFarmer Loc: Escaped from the NYC area, back to MA

Only 44 pages so far. Anyone know what the record is?

petrochemist Loc: UK

I guess I didn't word that well!
When shooting RAW the embedded JPEG will be developed using the same settings that would be used for shooting JPEG direct.
If these settings are changed for viewing the RAW file then you are doing post processing, even if not intentionally.

I'm not sure about other software but I know my prefered software does show the embedded JPG initially when working with RAW files. Even if not using the embedded jpeg software will usually have the option of using the white balance, exposure, sharpening etc 'as shot'.

DirtFarmer Loc: Escaped from the NYC area, back to MA

The embedded jpg is developed by the camera using the camera settings.
The software reads the raw file and has access to that jpg so it can display it. But that isn't the image you want to see because you want to see the effect of editing. So as soon as it can, the software will apply some standard settings or a preset and demosaic the image and display that. It MAY differ from the embedded preview because (1) it's possibly using different settings; (2) it's probably using different algorithms on the demosaiced data. The software can only match the camera settings if the camera settings are contained in the metadata of the raw file, something that will vary between camera manufacturers and maybe even camera models and maybe even firmware updates.

As you imply, other software may do different things. My software is Lightroom/Photoshop. Lightroom has some presets but Photoshop doesn't unless the image comes from Lightroom, then it uses the lightroom settings (if you have edited the image it can use the current settings rather than the generic presets). I normally import the image to Lightroom first, then if it needs it, Photoshop later.

Miker999

As I mentioned before, I shoot both raw and jpeg in BW. The raw shows up as BW in my software and it asks if I want to see the original. ONCE, I was asked by my Daughter In Law if I had a colored version of the image (my grandchild), Fortunetly, I had the raw and was able to provide what she wanted. That alone is a reason for me to shoot both. Anyway, 44 pages of an endless debate is too much.

Blenheim Orange Loc: Michigan

I am not saying thousands per second. Let's say that 24 images a second were being produced and you had live view on for oh, say, 5 minutes and the subject and/or the camera were moving. That would mean 7,200 different images visible on the camera's LCD screen. Those images cannot all be embedded JPEGs, can they?

Another question is this: if embedded JPEGs are what we see when we open a raw file, the why do programs like Windows Photos and IrfanView depend upon LibRaw to render raw files as bitmaps? Why not just access the embedded JPEG and display that?

DirtFarmer Loc: Escaped from the NYC area, back to MA

Ah. Misuse of the word 'instantaneously' when you meant '5 minutely'?

They are not all embedded jpgs. The embedded jpg is the one that is current when you release the trigger.

The jpg that is embedded is not the final image you want when you are in the editing program. The editing software applies its own (not necessarily the camera's) settings to the raw data to produce an image. Edits are done by modifying the software settings and re-demosaicing the raw data. They don't depend on LibRaw (a specific program). They have their own demosaicing algorithm to render the raw data as a bitmap. From the beginning, the camera's jpg is no longer the correct image.

Blenheim Orange Loc: Michigan

Apparently there is more than one JPEG embedded in raw files, and the quality is variable and not necessarily the same as the outputted JPEG that is written to the card. Also not all viewers/editors display the embedded JPEG and not all embedded bitmaps in raw files are JPEGs.

I am not sure why an editing program would show an embedded JPEG initially when working with raw files. Are you sure that is what is happening?

DirtFarmer Loc: Escaped from the NYC area, back to MA

I actually don't know if it is happening now. I noticed it many years ago but my computers are now fast enough that if it's happening it goes so fast I don't notice it. The preview is there for your File Explorer or Finder to have something to display without having to go through demosaicing (which needs settings to look good). If the computer generates a demosaiced image fast enough with the editor's preset, there's no need to use the embedded preview. But if the preview weren't there you wouldn't be able to use IrfanView or FastStone on your raw files.

Blenheim Orange Loc: Michigan

Yep. My mistake. "Pretty damned quickly" would have bee better, since a lot of them would need to be produced in a short period of time.



That makes sense.



I think that programs other than the proprietary software from the camera manufacturer must depend upon LibRaw or dcraw.

The camera manufacturers are using proprietary raw formats and encrypting portions of the files. We have even seen different formats from the same manufacturer. That makes for a big mess. Most of the work to untangle the mess so that we a edit raw files with programs other than those put out by the camera manufacturers has been done by just two people: Dave Coffin (Dcraw) Phil Harvey (LibRaw). A bunch of programs have relied on one or both, including Adobe raw convertor.

Interesting article here:

https://www.libraw.org/articles/2-ways-to-nowhere.html

Quotes from the LibRaw site:

If the author of a program declares that his program provides support for the majority of data formats, it means that most probably he is using dcraw source texts either as the ready solution or as a documentation. Among others who uses this approach is such a major player as Adobe. It is nothing less but amazing that such a huge industry largely depends on just one person and 8 thousand lines of code written by him.

...

The manufacturers explain why they prefer not to disclose the RAW formats. Usually their explanations add up to the following simple reasons:

• Reserved and new data fields can reveal some trade secrets to competition.

• Quite often the data fields are added just in case ; as soon as the camera design allows to get this information it should be preserved and it may be used later to improve RAW conversion. Such fields include for example diagnostics and service fields. To document all these fields means to take responsibility for their contents and to maintain their presence in future releases of firmware and even future cameras.

• To open a format means to trigger an unnecessary public discussion. Let's say users can access the information that registers the focusing distance. The immediate reaction of certain users will be to get a ruler to check the focusing accuracy to motivate his claims that the camera doesn't focus correctly. In the recent case over the out-of-focus problems with 1D MkIII moral damage and financial losses of Canon could be much worse if only the respective field in RAW data would be officially documented. And of course such claims would not be limited to just Canon.

• Some camera manufacturers are trying to get additional money out of RAW converters. Not long ago native RAW converters had no competition at all to the extent of monopolizing the market. Of course they prefer to maintain a competition at minimum. It is not unusual to hear from camera manufacturers that only their converters do the justice to their cameras while third party converters only compromise their cameras decreasing image quality, distorting colours and sacrificing resolution and on top of that adding noise.

Manufacturers claim sometimes that encoding of data fields is done in the best interest of the users, that only such encoding allows to ensure data integrity and also to prove authenticity and authorship of the original shot. Those of our readers who are familiar with the modern state of cryptography will surely smile here. It looks like the manufacturers are not overly concerned with providing us with convincing and satisfactory arguments.

DirtFarmer Loc: Escaped from the NYC area, back to MA

Interesting. Had not seen that.

Blenheim Orange Loc: Michigan

IrfanView doesn't display JPEGs, it uses LibRaw to render the raw file as a bitmap. It uses the camera manufacturer's settings to make the image look good. A lot of programs do that, including RawTherapee, Adobe Camera Raw, Affinity Photo, Windows Photos, Darktable, Topaz Studio, etc.

It is a huge amount of work to reverse engineer the various proprietary file formats, and LibRaw is open source and free to use, so why wouldn't image editing software companies take advantage of that?

Blenheim Orange Loc: Michigan

Hey! Pass that popcorn would ya?

I have learned a lot as a result of this thread, and I hope my comments haven't been too stoooopid. Ignorance I'll admit to, which is why I have hung in there and weathered the inevitable raw versus JPEG sh*tstorm.