Samsung Makernote Tag 0x0045

[Klaus_Homeister]

Hi Phil,

Samsung Makernote Tag 0x0045
"RawCompressionMode"

I don't think that it is related to compression.
It is present in cameras without any compression.
at least in NX-200 files it can vary  -  '0' or '1' without any change in RAW-Data Compression (but in exposureMode!).
So let's look at Samsung-buggy TIFFTag 0xA402 ExposureMode!

if TiffTag_0xA402 is correct, then 0x0045 is set to '0'
if TiffTag_0xA402 is illegal set to '3' (unknown Exposuremode) , then 0x0045 is set to '1'

For me 0x0045 is only an indicator for Standard-Exposuremodes or Extended/smart/whatever... SamsungModes are set and specified elsewhere in crypted data I don't know.


Next is Tag 0x0050

Here is a corelation to buggy TIFF-Compression and CFA-Pattern


if 0x0050 states a '-1':
-------------------------
That's for NX10/11/100
you have to fix TIFFTag 0x0103 from 'samsung_compressed' to  'packed_raw'
<

if 0x0050 states a '+1':
-------------------------
you have to check over 3 compressionmodes used by Samsung

EX1/EX2/WB2000
> [TIFF packed_raw)  gets unpacked_raw

NX20/NX200/NX210/NX1000
[TIFF samsung_compressed)  gets packed_raw
<

if 0x0050 states a '0':
-------------------------
CFA-Pattern has to be fixed from dcraw-style 0x94949494 -> 0x61616161
NX300/NX2000/EK-GN120(Galaxy-NX)
<


If this tag is not present at all, then TIFF-Settings are valid as they are.





Sounds crazy... but it works.

And when you look at samsungs Metadata at all ... there are many crazy things.
perhaps another way of encryption for them .... Buggy TiffTags are Samsung-Features ... not bugs ;-)
hmmmh....


Greetings from Germany

Klaus

[Phil Harvey]

Hi Klaus,

Thanks for this note.  I'll look into this when I get a chance and check my sample Samsung image, then post back here afterwards.

- Phil

[Phil Harvey]

Yes, very crazy.

For now I'll comment out tag 0x0045.  I don't know what to do with the rest.

Thanks for the information!

- Phil

[Klaus_Homeister]

For now I'll comment out tag 0x0045.  I don't know what to do with the rest.

That's fine.
because the info to Tag 0x0050 requires that dcraw works correct.
And to that point I get unsure.
Dave's 'Samsung_load_raw' loads RAW-data in INTELorder for general.
And he swaps the CFA-Pattern for nearly all cams using that routine.

But newer Samsung state in Tag
TIFF_IFD 0xA101 (ASCII×1) VAL #00004D4D  the ByteOrder -> 'MM' Motorola

Now im writing my own load_raw_routines with respect to Tag 0xA101 ... and get crazy once more.
Everything is the opposite But then works with Samsungs stated CFA-Patterns.

Now I have to do a lot of more work until I really know which CFA and what algorithm of loading is correct.

Correct info for now is:
TIFF_TAGS:

0xA010 LONGx1 Samsung_RawRowOffsets  -> is a Pointer to a list of Offsets. one for each row in image.

0xA011 LONGx1 Samsung_RawRowOffsetsLen  -> is the length of this list. (image-rows x sizeof(LONG))

0xA101 ASCIIx1 Samsung_RawByteOrder  ->  is the ByteOrder of the RawData (!!) (LEN is TWO and not one like Samsung says)

0xA102 ASCIIx1 is once more an unknown 'always_NULL_Tag' of Samsung.

I haven't seen those Tags specified by TIFF so I think that they're private tags  for Samsung only.


And by the way for Samsung Makernotes

Newer Tags 0xA055|0xA056|0xA057 have always content identical  to 0xA050 'Distortion'
So I think it's simply a three-channel-version of that.
Key-index is on '8' for start of tag 0xA055 and then roll key as usual and ADD the Keys without reset in next two tags..



greetings from wet and cold Germany
Klaus

[Phil Harvey]

Klaus,

Thanks for this.  It was very useful information in fixing a problem writing some SRW files.

- Phil

[Klaus_Homeister]

Hi Phil,

I had some time to write a simple RAW-converter that strict makes it's setup related to Meta-Tags.
DCRaw makes too many hidden changes in Setup for Samsung-Cam which I haven't seen earlier. 

Now things get clear:

When you keep in mind that the NX200 was very buggy in Metadata at all ... you get a clean logic.
For NX200 you will always have to check for especially THIS Cam and force <uncompressed_RAW> and <bitdepth 12>
And take care not to make this Fix for 'NX2000' !!!


The rest is simple for _all_ Samsung-Cams.


TIFF_DIR:
------------
TIFF-Compression_0x0103:

If <PACKED_RAW> is given -> it is always <uncompressed_RAW>
If <SRW_compressed> is given -> you have to check for Tags 0xA010(RowOffsetList) and 0xA011(RowOffsetListLen)
if they're both NOT AVAILABLE -> it is <PACKED_RAW>
if they're both AVAILABLE and each VALUE>0 -> it is correct <SRW_compressed>

For all other Compression_Setups 0x0103 gives correct Data. (keep in mind: except NX200)


by the way ... 0xA101 is LEN=2 & Type ASCII ... the Samsung_Tag for the File-Byteorder 'II' or 'MM' ... a nonsense-tag because you have already _to_know_ to get here ... ;-)


Makernotes:
--------------

forget Tag 0x0045 for now. It is definitely related to RAWData ...
But in very rare files this value can vary <0 OR 1> and is NOT <fixed per Cam> like I said before. 
In such files it seems to be dependent on ISO-Setup and in HighISO-Modes the format of RAW-Data can be affected ... especially borders and rawimage_size.
Ignore it for now until things get clear.
I reckon In-Cam-Noisereduction works on RAWData too - and that can affect raw_size & borders.


Verified for now is:

Tag_0x0040: RAWData_ORDER   <0 INTEL>  (maybe  <1 MOTOROLA> but no Cam uses Motorola>

Tag-0x0050: RAWData_CFA -> modifies CFA-Pattern given by TIFF_TAG

<0>  UNCHANGED
<1>  SWAP-CFA  (dcraw-like: 0x1E <> 0x4B | 0x4B <> 0xE1)
...
<-1> ROLL-CFA   (dcraw-like: 0x1E <> 0xE1 | 0x4B <> 0xB4) (and in addition do the job of missing 0x0040 -> RAWDataOrder=INTEL)

(THAT'S DIFFERENT TO WHAT I SAID EARLIER!! ROLL!!)

...

That's all!

DCRaw makes many hidden changes in the background to get a bigger imagesize than the safe imagesize given by Metadata. That's why this Software makes it hard to verify all those Tags.


Greetings from Germany
Klaus

P.S.: by the way some new Bugs I have found:

Some early Versions of Galaxy-NX have an preproduction-Firmware and are "in the wild" ...
if you have an TIFF_"CFAPATTERN2" identically to TIFF_"StripByteCounts" -> It's a bug an you can fix it with pattern GRBG (0XE1)

Samsung simply copies the value of ExposureProgram into the value of ExposureMode in Exifdata. That's a Bug and no magical extended ExposureMode :-(

NX1 and NX500 have always one Tag more in Makernotes than given by directory-entries. The unknown 0xA061 is the hidden last one.

And for RAW-development of NX1/500 very important:
Some RAW's recorded in poor low lightning can setup to 14Bit. But in case of underexposure they're sometimes stored in 12Bit-Data within 14Bit-Values!!
You can check those Exposures with Tag 0xA048. The maximum Values in such Files are reduced from 16383 down to 4095.
When a Software doesn't respect that, the image gets four times darker than correct and then get finally black by wrong maximum in gamma-correction and matrix-process.
A RAW-Development-Software should set the maximum saturation here in Tag 0x0048 and NOT simply set 12bps=4095 or 14bps=16383!
That prevents for some rare 'near-black dark images' some people getting confused on ... or expecting an damaged Sensor and so on...

For me 0xA048 gives the valid data-range for processing pixels ...
4Channel-Minimum <0 0 0 0>
4Channel-InputMaximum  <4095 4095 4095 4095> or  <16383 16383 16383 16383>
4Channel-OutputMaximum <4095 4095 4095 4095> or  <16383 16383 16383 16383>


ok that's enough for now

bye
Klaus

[Phil Harvey]

Hi Klaus,

I have to agree that Samsung maker notes are very buggy.  They need better programmers.

The information you provide is interesting, but I don't think that it is particularly relevant to ExifTool since it deals with image data (and how to decode it), and not metadata per se.  Correct me if I'm wrong, or if there is something you would like to see added/changed in ExifTool.

- Phil

[Klaus_Homeister]

Hi Phil,

I don't think so for Makernotes.
The part of Tiff-Specifications  is another matter. 
When Samsung isn't able to respect Standards, then this (maybe?) shouldn't be supported.

For me it's enough to show the Info in Makernotes.

0x0040 RawByteorder with value 0:INTEL
0x0050 RawCFAPattern with info that pattern given by Tif-Standard needs to be > 0:Untouched 1:swapped -1:rolled

And it would be fine, but is not needed: a unmistakeable comment that Tiff-Metadata related to RAW-Data often isn't reliable for Samsung.

That's enough

The rest was to show and explain why this short info is correct.

greetings
klaus

[Phil Harvey]

Hi Klaus,

I understand.  Thanks for the explanation.

- Phil