Big or Little, that's the problem

Software RawTherapee
1

Hi,

The byte order of EXIF data in Nikon’s NEF is understood as Big Endian.
Nikon’s genuine software such as NX-D change it into Little Endian when converting NEF files into jpeg and Tiff format.
Nikon’s sofwares cover both Big and Little Endian jpeg and only Little Endian Tiff, leaving Big Endian Tiff unavailable.
Adobe’s softwares including Photoshop and LR produce Little Endian Tiffs when they develop NEF files.
GIMP produces Little Endian Tiffs when they develop NEF files.
Dcraw produces Little Endian Tiffs when they develop NEF files.
Darktable produces Little Endian Tiffs when they develop NEF files.
Raw Therapee produeces, however, Big Endian Tiffs when they develop NEF files.

My questions are:

  • Would RT have any disadvantages if it adopt Little Endian Exif when converting NEFs to Tiffs ?
  • Would it be technically hard ?
  • If not, why don’t you think of it ?
2

This should be handled by Adopt libexiv2 or ExifTool for metadata handling · Issue #3801 · Beep6581/RawTherapee · GitHub

3

Thanks for your reply.
But I do not understand what you are saying in the post of which link you showed.
In a word, will RT change its mind as regards Big Endian of Nikon’s NEF in the future as most other softwares do, or not ?
Best,

4

When writing tiff RT currently uses the byte order from exif, which is the byte order from the NEF in this case, which is Big Endian.

What would be the advantage of writing Little Endian tiff?

Technically it would be easy to ignore the byte order from exif and always use Little Endian (or Big Endian) for writing tiff. But that would be for all type of input files, not just NEF. Ignoring the byte order from exif only for NEF would be much more work.

5

Hi heckflosse

Thanks for your intervention.

What would be the advantage of writing Little Endian tiff?

If you read my former post carefully again, you will find that:

Nikon’s sofwares cover both Big and Little Endian jpeg and only Little Endian Tiff, leaving Big Endian Tiff unavailable.

6

Do you mean Nikon’s software can’t read Big Endian Tiff?

7

They don’t as far as I know.

8

Page 26

‘MM’ and ‘II’ byte order. TIFF readers must be able to handle both byte orders.
TIFF writers can do whichever is most convenient or efficient.
9

I’ve been aware of that since long.
But it might be legally non-binding as you see Nikon remain the same.

10

You can use the -endian flag in imagemagick to convert between endianness

1 Like
11

Hi, just want to say that I had the same TIFF problem some time ago, and I ended up with abandoning Nikon software (well, not just for this of course). I have no regrets at all, some rare things I had to lose, but much more are those I gained. But I understand your question.

12

Sorry for my misleading argument, but I have identified and settled the problem.
Actually, it is NOT Big Endian BUT some specific Exif data that prevent Nikon’s software from reading Tiffs produced with RT.
Precisely, “CFARepealPatternDim” and “CFAPattern” are concerned.
With these data being deleted, Tiffs produced with RT get compatible with Nikon’s software.
But I do not know the reason why Nikon avoids Tiff with those data.
Maybe this is a little discovery as there has been no report like mine on internet.

Best,

13

Educated guess: A TIFF with those raw specific values set (“CFA” stands for “Colour Filter Array”, i.e., Bayer pattern) might look like a raw file to the Nikon software and make it choke when the actual file isn’t what it expected.