Why editing software need to be updated for Z8?

[csn]

I'm kinda puzzled by why image editing software need to be updated in order to process Z8 files?

Given that the guts of the Z8 are essentially the same as that of the Z9, shouldn't they be able to handle both files as one and the same?

For example, I use DxO PL6, which supports Z9 RAW but will have to wait till July (of this year) to be able to precess my Z8 files with it. Makes no sense to me.

 

[areallygrumpyoldsod]

I don't know if the OP got the email today as well, but DxO just put out an update for PL6 that includes full support for the Z8. I downloaded it and tried it. It works for lossless and HE raw files. It also downloaded the optics modules for the Z8 and 24-70 f/2.8 and 50 f/1.2 combos as well which were the lenses used.

Hi -- both PL6 and Pure Raw 3 work with the Z8 Lossless Raw. I use PR3 as a raw developer and have processed images in both SDR and HLG Tone mode. However the DNG's from PR3 for HLG came out 2 stops (EV) darker than those developed in NXS.

I have asked DxO how they take account of Lossless RAWs shot in Rec.2020 colour space.

 

[Thom Hogan]

I'm kinda puzzled by why image editing software need to be updated in order to process Z8 files?

Given that the guts of the Z8 are essentially the same as that of the Z9, shouldn't they be able to handle both files as one and the same?

Because virtually all software works like this (pseudo code):

READ EXIF DATA
IF CAMERA = KNOWN VALUE PROCEED;
ELSE ERROR

For those that have been around as long as I have, you probably remember me and others showing how to use an EXIF tool to just change the camera's name, and voila, the software works with the image (assuming it had virtually the same sensor aspects as a previous camera).

It appears that Adobe and a few others got an early warning from Nikon about the Z8 being a mini Z9, and they just changed that second line to:

IF CAMERA = Z8 or Z9 PROCEED;

However, this isn't perfect. Since you can now record NEF files using HLG, converters that did what I just said don't recognize the Color Space of the image properly (it should be BT.2020, not sRGB or AdobeRGB). Some (e.g. Adobe) get away with this because they just discard the Color Space info and use a large Color Space to begin with. But there are still open questions as to whether that's the right thing to do.

Finally, if the raw file is High Efficiency instead of Lossless Compressed, the raw converter has to know how to decode the compression, which requires a tool from intoPIX.

 

[just Tony]

at the very least, the camera model in the exif is different

This is a single line item in the exif. It shouldn't require creating a whole new file type!

Software that has nothing in it yet to explicitly handle the new camera would not typically jump to the conclusion that it could “just go ahead and give that a try”. Such a pathway would have to have been designed in even if it seems to us like it might be trivial thing.

but we don’t know what else Nikon has changed in the raw data or exif of the NEF file

The sw vendors have presumably received the sdk from Nikon that tells them exactly what changed, and if they aren’t ready to release yet they have some sound business wisdom behind that decision. I’ve released a lot of sw myself but never without having tested it first on production-spec hardware.

--
Wag more; bark less.

 

[BGD300V1]

Correct me if I'm wrong, but my understanding is that the Z9 and Z8 are internal twins, i.e., same sensor, same processor, etc. That is, the Z8 is a Z9 sans vertical grip. Therefore, it makes no sense for the Z8 to have an entirely new file system.

BUT ...

Those are hardware. The processing software is obviously different because there are additional file formats, two different types of card, Battery control, etc.

We used to use Univac 1108s to calculate satellite orbital parameters. The bank down the street used them for financial calculations. Same processor and mass storage but different.

 

[Thom Hogan]

at the very least, the camera model in the exif is different

This is a single line item in the exif. It shouldn't require creating a whole new file type!

It's a single item in the EXIF which would allow software that understands what that means to comprehend all the other things in the file. And even between the Z9 and Z8 there's a really significant one that is tripping up software that doesn't understand that: Color Space. An HLG-powered NEF uses BT.2020 Color Space and a different tone curve, for instance.

But Nikon has a long history of adding and changing things in the both the EXIF MakerTags as well as the data contents stored in a file. Thumbnails change a lot, for instance (some software may use them, particularly in catalog/browsing modes). Nuanced changes, such as those to white balance, also happen with regularity (newer Nikon's support a Natural Auto as well as Auto, for instance).

Basically, a piece of software, once it knows what camera it is dealing with, can look for other information it may need if the file format is known. If it doesn't know that changed information, it is making assumptions that might make the rendering wrong.

but we don’t know what else Nikon has changed in the raw data or exif of the NEF file

Correct me if I'm wrong, but my understanding is that the Z9 and Z8 are internal twins, i.e., same sensor, same processor, etc. That is, the Z8 is a Z9 sans vertical grip. Therefore, it makes no sense for the Z8 to have an entirely new file system.

Let's use proper words here. Both the Z8 and Z9 use the DCF standards when it comes to file system. What we're talking about here is file contents. The Z8 and Z9 file contents are different in a few ways, and some of us are still trying to reverse engineer what those all are. If, on the other hand, you use the Nikon SDK for everything in your software, you could simply use the SDK's API to get access. However, I'm not sure the Z8 additions are available yet (they might be, I haven't checked for a few days).

 

[Thom Hogan]

One possibility is If Nikon tweaked the compression algorithm that could cause differences, and LR may need to know about such changes to the algorithm so it can decompress the files properly.

To my knowledge, Nikon has not changed the Lossless Compressed algorithms. And the High Efficiency algorithms are hardwired in the EXPEED chip using intoPIX IP. They require a software tool from intoPIX to decode.

This is one reason why some raw converters seem to work: they assume the raw data block is the same (and it is, for the reasons I note, above). But other key need-to-know things live outside the data block in the EXIF data, particularly the MakerTags.

 

[Thom Hogan]

Yes, and it's been done before - images from new versions of cameras have been postprocessed by hacking the EXIF file. But this assumes that indeed the RAW files are identical, and doesn't always work.

Let me correct your language: doing the name swap trick assumes that raw data block within the file is recorded identically, and accessed the same way. With a lot of Nikon cameras, that has been the case when the new camera used the same/similar image sensor.

You are assuming that 3rd parties would have information about the nature of files for far-future camera releases which would enable them to precode for a whole line of cameras. That's HIGHLY unlikely.

Actually, I know that to be true. I can't speak to the cases where it was true, as that is confidential information.

Even partnering 3rd parties wouldn't have this sort of technical info given to them until a camera is finalized and first production runs have begun.

Production runs start far before the camera actually ships to customers. Typically there's a window of one to three months, and it's been rare that new firmware was deployed during that initial run. Moreover, file format tends to lock fairly early in the design process.

Then they get to decide when they can release a postprocessing product that conforms to their quality standards. The postprocessing folks are doomed to a life of reacting.

Both statements are true. However, in my observation the first statement has varying level of acceptances (conforming to quality standards), even within the same company.

 

[FrankG]

I'm kinda puzzled by why image editing software need to be updated in order to process Z8 files?

Given that the guts of the Z8 are essentially the same as that of the Z9, shouldn't they be able to handle both files as one and the same?

For example, I use DxO PL6, which supports Z9 RAW but will have to wait till July (of this year) to be able to precess my Z8 files with it. Makes no sense to me.

Solved: DXO just released Photolab v6.7 with full support for the Z8:

1.454 neue optische DxO-Module - DxO

DxOs bahnbrechenden optischen Module gewährleisten höchste Bildqualität, egal ob Sie mit Einsteiger- oder Profigeräten fotografieren.

www.dxo.com

I downloaded and installed the update yesterday for support for the 800PF which is also included in this update. I don't have the a Z8 but I expect this release will work.

Frank

 

[mosswings]

Yes, and it's been done before - images from new versions of cameras have been postprocessed by hacking the EXIF file. But this assumes that indeed the RAW files are identical, and doesn't always work.

Let me correct your language: doing the name swap trick assumes that raw data block within the file is recorded identically, and accessed the same way. With a lot of Nikon cameras, that has been the case when the new camera used the same/similar image sensor.

Yes, that's more precise.

You are assuming that 3rd parties would have information about the nature of files for far-future camera releases which would enable them to precode for a whole line of cameras. That's HIGHLY unlikely.

Actually, I know that to be true. I can't speak to the cases where it was true, as that is confidential information.

You would know better than I. To be sure, with strategic 3rd parties under heavy NDA I could see a long horizon for future production notification that would facilitate writing efficient code for a group of cameras. I just couldn't see this for most 3rd parties. Thinking of the recode scramble Sigma had to go through every time Nikon changed something in the f-mount interface.

Even partnering 3rd parties wouldn't have this sort of technical info given to them until a camera is finalized and first production runs have begun.

Production runs start far before the camera actually ships to customers. Typically there's a window of one to three months, and it's been rare that new firmware was deployed during that initial run. Moreover, file format tends to lock fairly early in the design process.

See above rethink on strategic partners.

Then they get to decide when they can release a postprocessing product that conforms to their quality standards. The postprocessing folks are doomed to a life of reacting.

Both statements are true. However, in my observation the first statement has varying level of acceptances (conforming to quality standards), even within the same company.

Yes. If the postprocessing product is just awaiting a final camera name for the release, that's a different set of standards than those for the foundational coding underpinning a whole product group. But I'd also think that the name would have been settled long before that (and not necessarily something marketing-simple like "Z8").

 

[jfriend00]

I'm kinda puzzled by why image editing software need to be updated in order to process Z8 files?

Given that the guts of the Z8 are essentially the same as that of the Z9, shouldn't they be able to handle both files as one and the same?

For example, I use DxO PL6, which supports Z9 RAW but will have to wait till July (of this year) to be able to precess my Z8 files with it. Makes no sense to me.

First, the RAW images are labelled as Z8 images, not Z9 images.

Doch!

Second ,...

Third, ...

Fourth, ...

Fifth, ...

A digital camera is an embedded system. Basically, a small computer built to perform a specific task, i.e., record images. So with that in mind, when we have two, essentially identical systems, i.e., same circuit board, same image sensor and processor, and both running close to identical firmware, I would expect them to utilize the same file system and produce the same binary output. That some parameters change internally, like model number, etc., should be irrelevant.

Given those two systems, an image processing software that can interpret files produced by one system should be able to interpret files produced by the second system. Or, at least, that would be my expectation. Of course, it is always possible to monkey around with the system such that this won't be the case.

It's a bit hard for us to know that there are ZERO differences in the RAW files or colorspaces or metadata that describes things like distortion correction, vignetting correction, etc... between a Z8 and Z9 file and that zero differences will be true forever (including all future firmware updates). It seems that the actual camera it came from should still be labelled in the RAW file.

What would be useful is if Nikon has a RAW file version number and RAW processors could use that version number (say x.y.z kind of version). If X is different, then the whole raw file is different and a RAW processor should not attempt to do anything with a value of X that it wasn't already tested with (like a new, incompatible mechanism for color). If Y is different, then define some set of parameters that might be different (perhaps how distortion, vignetting, lens metadata works) that could allow a RAW processor still render the image, but not optimally. If z is different, then this is just a tweak of some kind that shouldn't affect rendering in any major way.

Then, the Z8 raw file could at least by the same x.y version as the Z9 and RAW processors would be happy to render it.

This type of mechanism seems better than lying about what camera it comes from and pretending to be a Z9.

 

[csn]

I'm kinda puzzled by why image editing software need to be updated in order to process Z8 files?

Given that the guts of the Z8 are essentially the same as that of the Z9, shouldn't they be able to handle both files as one and the same?

Because virtually all software works like this (pseudo code):

READ EXIF DATA
IF CAMERA = KNOWN VALUE PROCEED;
ELSE ERROR

For those that have been around as long as I have, you probably remember me and others showing how to use an EXIF tool to just change the camera's name, and voila, the software works with the image (assuming it had virtually the same sensor aspects as a previous camera).

It appears that Adobe and a few others got an early warning from Nikon about the Z8 being a mini Z9, and they just changed that second line to:

IF CAMERA = Z8 or Z9 PROCEED;

However, this isn't perfect. Since you can now record NEF files using HLG, converters that did what I just said don't recognize the Color Space of the image properly (it should be BT.2020, not sRGB or AdobeRGB). Some (e.g. Adobe) get away with this because they just discard the Color Space info and use a large Color Space to begin with. But there are still open questions as to whether that's the right thing to do.

Finally, if the raw file is High Efficiency instead of Lossless Compressed, the raw converter has to know how to decode the compression, which requires a tool from intoPIX.

Thanks. This has been most helpful. I've been digging into the libexif library to understand EXIF better.

Could you point me to some more in-depth material on what the processor does or is that all proprietary? Are there any publicly available SDKs or does one have to be a registered developer to get access?

Thanks

 

[SoCalAngler]

Are there any publicly available SDKs or does one have to be a registered developer to get access?

Thanks

For Nikon you can start here.

https://sdk.nikonimaging.com/apply/

You need to apply and register. No cost.

I have not personally gone through the application process.

Canon, Sony, Olympus, Fujifilm, and others have a similar process.

 

[csn]

Are there any publicly available SDKs or does one have to be a registered developer to get access?

Thanks

For Nikon you can start here.

https://sdk.nikonimaging.com/apply/

You need to apply and register. No cost.

I have not personally gone through the application process.

Canon, Sony, Olympus, Fujifilm, and others have a similar process.

Sweet! Thanks!

 

[BGD300V1]

What would be useful is if Nikon has a RAW file version number and RAW processors could use that version number (say x.y.z kind of version). If X is different, then the whole raw file is different and a RAW processor should not attempt to do anything with a value of X that it wasn't already tested with (like a new, incompatible mechanism for color). If Y is different, then define some set of parameters that might be different (perhaps how distortion, vignetting, lens metadata works) that could allow a RAW processor still render the image, but not optimally. If z is different, then this is just a tweak of some kind that shouldn't affect rendering in any major way.

I can't imagine that the .NEF file did not contain that information as the Camera Model and Firmware Version numbers for body, lens, and accessories.

Distortion control for example would need the lens identity and firmware version for the lens. Knowing that an FTZ was in place would help with identifying the communications protocols and handling the differing control requirements of Non-Z lenses, etc.

I'm pretty sure that the Nikon System and Software engineers have thought this stuff through pretty thoroughly before committing to a production firmware build.

Or, as a hardware engineer once asked me "You guys can fix this in software, right?"

 

[Thom Hogan]

Could you point me to some more in-depth material on what the processor does or is that all proprietary?

My books probably contain as much information as is publicly known about EXPEED. Like a lot of the SoC variations the camera makers use, it's a set of ARM cores coupled with proprietary IP cores. In the case of EXPEED7, one of those IP cores is intoPIX's.

Are there any publicly available SDKs or does one have to be a registered developer to get access?

The available SDK tends to mostly be API calls into the "black box" of the processor. Amazingly, I can trace a lot of that API to a document I was given under NDA back in 1993 when my company was pitching Nikon on software.

To be complete, you'd also need to apply to intoPIX for their SDK, as well.

 

[ggbutcher]

What would be useful is if Nikon has a RAW file version number and RAW processors could use that version number (say x.y.z kind of version). If X is different, then the whole raw file is different and a RAW processor should not attempt to do anything with a value of X that it wasn't already tested with (like a new, incompatible mechanism for color). If Y is different, then define some set of parameters that might be different (perhaps how distortion, vignetting, lens metadata works) that could allow a RAW processor still render the image, but not optimally. If z is different, then this is just a tweak of some kind that shouldn't affect rendering in any major way.

I can't imagine that the .NEF file did not contain that information as the Camera Model and Firmware Version numbers for body, lens, and accessories.

Distortion control for example would need the lens identity and firmware version for the lens. Knowing that an FTZ was in place would help with identifying the communications protocols and handling the differing control requirements of Non-Z lenses, etc.

I'm pretty sure that the Nikon System and Software engineers have thought this stuff through pretty thoroughly before committing to a production firmware build.

Or, as a hardware engineer once asked me "You guys can fix this in software, right?"

Got me curious, so I grabbed one of my Z 6 NEFs and ran it through exiftool, grepping for any tag with "version" in the name:

[ExifTool] ExifToolVersion: 12.51
[EXIF] GPSVersionID: 2.3.0.0
[MakerNotes] MakerNoteVersion: 2.11
[MakerNotes] VRInfoVersion: 0200
[MakerNotes] PictureControlVersion: 0300
[MakerNotes] ShotInfoVersion: 0800
[MakerNotes] FirmwareVersion: 01.01.e0
[MakerNotes] FirmwareVersion2: 01.01.00
[MakerNotes] FirmwareVersion3: 01.01.00
[MakerNotes] ColorBalanceVersion: 0800
[MakerNotes] LensDataVersion: 0800
[MakerNotes] FlashInfoVersion: 0108
[MakerNotes] MultiExposureVersion: 0101
[MakerNotes] AFInfo2Version: 0300
[MakerNotes] FileInfoVersion: 0100
[MakerNotes] RetouchInfoVersion: 0200

Having specifically poked around the Z-series lens corrections, I think the LensDataVersion is about what fields are available. The actual lens correction parameters for distortion and vignetting appear to be in the metadata, so easy-peasy, just use 'em, no worry about the particular lens version number. Not really, need to figure out what of a variety of distortion algorithms are used, etc. NDAs are handy in that regard...

Software that use the lensfun lens correction library are quite dependent on the camera and lens model to determine what parameters from their extensive database to apply. THAT can be a mess, as presence of such data for the lens in the image metadata is spotty.

 

[areallygrumpyoldsod]

All the main tools (Adobe, C1 and DxO) and DxO PR3 and Topaz Photo AI have now been updated to accept Z8 Lossless RAW files shot in both SDR and HLG Tone Modes.

As noted in another thread - the only difference I see is that all bar NXS appear to under-develop Lossless RAW HLG files by 2 stops. This make me doubt if the current versions correctly understand how Nikon is using Rec.2020 in these files.

What appears "good" is that the image quality from both SDR and HLG (given that it is currently restricted to a higher min ISO) are very similar (once the -2EV is added back). Feedback has been sent as a question to all 3.

According to Alex - this format is normally supported by Raw Digger 1.4.6.761 - but the RAW image part is underexposed by 2 stops. All the images I sent to him were identically lit and exposed as shown below, which theoretically should have given the same results. HOWEVER, it is possible the camera is simply under exposing -- but why ???

• SDR - ISO 125, f/4.0 1/250 th (same scene same lighting)
• HLG - ISO 640, f/4.0 1/1250 th (same scene same lighting)

--
areallygrumpyoldsod
Nikon and Hasselblad shooter -- wildlife and and -- https://www.andymillerphoto.co.uk/ https://www.flickr.com/photos/ajm057/

 

[csn]

Could you point me to some more in-depth material on what the processor does or is that all proprietary?

My books probably contain as much information as is publicly known about EXPEED. Like a lot of the SoC variations the camera makers use, it's a set of ARM cores coupled with proprietary IP cores. In the case of EXPEED7, one of those IP cores is intoPIX's.

Are there any publicly available SDKs or does one have to be a registered developer to get access?

The available SDK tends to mostly be API calls into the "black box" of the processor. Amazingly, I can trace a lot of that API to a document I was given under NDA back in 1993 when my company was pitching Nikon on software.

To be complete, you'd also need to apply to intoPIX for their SDK, as well.

Good pointers, thanks. Also, your website is a great source of information on photography and related stuff. I have no idea how I managed to not find it after all these years as a hobbyist in photography.

 

[Thom Hogan]

As noted in another thread - the only difference I see is that all bar NXS appear to under-develop Lossless RAW HLG files by 2 stops. This make me doubt if the current versions correctly understand how Nikon is using Rec.2020 in these files.

That's my take, too. It has to do with the placement of tonal values. HLG extends (expands?) the highlight values that are available, which pushes the rest of tonal values down.

Back when the HDR video crowd was first pushing for HLG/HDR, one of the things I noted was that they were far less worried about noise than they were in going beyond 100 IRE. Even getting near 100 in the NTSC/PAL video broadcast world meant very little highlight detail. If you kept everything in the usual 10-80 IRE range you had a lot of mid-tone data, but shadows did the Velvia drop-to-black thing and highlights had little detail. These days we can "lift" shadows, but if you didn't capture the highlight detail, there's no place to recover it from.

I recall talking to someone about this very thing at NAB in 2016, but I can't find my notes on that at the moment.

 

[jfriend00]

What would be useful is if Nikon has a RAW file version number and RAW processors could use that version number (say x.y.z kind of version). If X is different, then the whole raw file is different and a RAW processor should not attempt to do anything with a value of X that it wasn't already tested with (like a new, incompatible mechanism for color). If Y is different, then define some set of parameters that might be different (perhaps how distortion, vignetting, lens metadata works) that could allow a RAW processor still render the image, but not optimally. If z is different, then this is just a tweak of some kind that shouldn't affect rendering in any major way.

I can't imagine that the .NEF file did not contain that information as the Camera Model and Firmware Version numbers for body, lens, and accessories.

Distortion control for example would need the lens identity and firmware version for the lens. Knowing that an FTZ was in place would help with identifying the communications protocols and handling the differing control requirements of Non-Z lenses, etc.

I'm pretty sure that the Nikon System and Software engineers have thought this stuff through pretty thoroughly before committing to a production firmware build.

Or, as a hardware engineer once asked me "You guys can fix this in software, right?"

But, apparently Nikon did not design a system that allowed them to identify Z8 NEFs as fully compatible with Z9 processing. Or, if they did, they didn't tell RAW processing companies about it. Because nobody had software that could automatically identify a Z8 file as something that could be processed with Z9 logic. That's what I'm saying they could have and apparently don't.

I'm assuming that lens profiles are separate parts of the RAW file and are not camera-specific (they are lens-specific. So, lens profiles that people would be shooting a Z8 with should already be known by RAW processors.

--
John