Samsung ES15 maker notes

[ajh]

I just got interested in maker notes a while ago when I was doing some random research on the JPEG-compression.
I quickly realized that my cheap Samsung ES15 was writing around 18KB of additional data to every JPEG-file.
This turned out to be Maker Note data.

I looked and found the descriptions of maker notes for Samsung cameras at
https://exiftool.org/TagNames/Samsung.html
but I don't think Samsung ES15 has maker notes of any of the types mentioned in there.

I didn't find the specs for the ES15 anywhere so I took a small step towards finding out on my own.

Here's my short and incomplete analysis.
- The maker notes starts of with an IFD.
- There are five entries in the IFD.
- The entries always seem to be of same size.
- The data at the fourth and fifth entries are filled with zeros.

Heres an example of my findings
http://repii.org/~ajh/es15maker/analysis.html

I also looked at some of the data in one of the sections and took a sample of numbers
I found in there and did a web search on them.

I found the same sequence of numbers in a lookup table in a source file that belongs to
Sun Microsystems (mp_lkup.c). You'll never guess what this code is used for.
It's used for generating lookup tables for AC and DC values in MPEG-files. Also used
for decoding said values. Could it be that Samsung ES15 stores some lookup tables
inside every JPEG-file? There's the camera functionality of rotating, mirroring and
modifying color of images on Samsung ES15. Could there be a table in every JPEG-file
to speed up or help these functionalities?

I did a test where I zeroed out the whole maker note section in a image file and uploaded
the picture back to the camera. Guess what? It took a lot longer for the camera to render the
image on the LCD screen. It took a lot longer for it to rotate and flip the image. When doing
the color modifying, the camera didn't remember the starting point so each color change chosen
from the camera menu changed the colors more and more. I mean, you could just rotate the
color adjustments over and over until the image wouldn't make any sense anymore.

I also searched the web to try to find out who exactly these Kim Miae and Lee BK fellas are

Anyway, I haven't had time to study this further. Hope this helps someone.

[Phil Harvey]

Very interesting.

The ES15 maker notes start with "STMN100\0".  Immediately following this are two 4-byte words giving the offset and length of the embedded JPEG preview image, which is also contained in the maker notes.  These are the only things currently decoded by ExifTool.  (This is the "Type1" Samsung maker notes.)  I don't see an IFD in these maker notes.

I think the pattern you recognized was from inside this JPEG.  This also explains why it takes longer to render the preview when you zero this out.

- Phil

Edit: After reading your web page, I see the IFD you mention, starting 0x2c bytes into the maker notes.  Nice.  I'll look into this further.

[ajh]

Yes, there is a thumbnail in the JPEG but it is located in it's usual place.
I haven't found anything that resembles a JPEG thumbnail in the maker notes section.

I have tried extracting this with exiftool but had no luck. If I recall correctly exiftool thought
the maker notes was "Type1" and told that there was a embedded JPEG. It failed to
extract that portion though and I think it's because there really is no image to be extracted.
I will test with exiftool again later today. Unfortunately I did this preliminary testing a while back
and I can't recall everything that I found out but I will atleast check which section it was where I
got the alleged lookup table numbers from.

[Phil Harvey]

I'm sorry, you're right.  The PreviewImage isn't stored in the MakerNotes.  It is after the JPEG EOI.

I've now got a working version of exiftool that properly decodes this IFD, but as yet it all tag values are still unknown.

Thanks for pointing this out.

- Phil

P.S. Sorry for the forum down time.  We had a power-out yesterday and some security software that I installed recently prevented the forum from coming back up automatically when the power was restored.

[Phil Harvey]

I just did a survey of all my Samsung samples for models which produce Type1 maker notes (starts with "STMN" followed by ASCII digits then a null terminator).  At position 0x2c in these maker notes, this is what may appear, from most common to least common:

1) The string "Park Byeongchan" followed by binary data. (21 models)

2) The IFD idenified by ajh. (13 models)

3) All zeros. (11 models)

4) The string "AWBMN_Prv". (1 model)

5) The string "MN_PRV". (1 model)

In the IFD version (2 above), there are always 5 entries in the IFD.  All of the entries begin with one of the following (with number of occurrences in brackets):

a) "Kim Miae" (13)

b) "Lee BK" (13)

c) all zeros (13)

d) "MN_PRV" (10)

e) "MN_ADS" (9)

f) "IPCD" (7)

- Phil

[ajh]

Thanks for the information Phil.

I was going to comment on the entry starting with MN_CAP, but then
I realized that it's actually inside the first IFD entry and therefore isn't a separate
section.

I'm currently trying to figure out what the data in these sections could possibly be.
One thing that came to mind is that they actually could contain a thumbnail image, just
not in JPEG format. Maybe they want the image in a faster simpler format like a bitmap.
An array of pixel values that the LCD screen can easily digest perhaps?
This would probably also support my experiences with the transformation functions on
the camera slowing down after zeroing out the maker note section.

I will try to convert the sections that look like arrays to pixel data and see what it looks like.
So far I'm only throwing very very wild guesses at it.

[ajh]

Just sharing one more thing I noticed.

When taking a picture in Auto-mode,
the data in the first section (MN_PRV) contains what looks like some sort of subsection
that starts with MN_CAP. MN_CAP string can be located usually at offset 0xb8e from
the start of maker note. When taking pictures in Program mode we don't have this
"subsection", it's just all zeroed out until the next section (Kim Miae) starts.

[Phil Harvey]

I encourage you to look into this data because it would be interesting to know what it is.

About zeroing out the makernotes:  I would suggest trying this test again, this time zeroing out only data from the IFD onward.  If you also zero out the PreviewImageStart/Length at the start of the maker notes, then the camera will slow down because it will need to regenerate the preview.  I have a sample ES15 JPEG here and I can verify that the preview image exists for this model.

- Phil

[ajh]

Thank you very much Phil.

You are absolutely right. I did not understand that the PreviewImageStart and PreviewImageLength
are actually present and valid. I somehow disregarded that when I found the IFD. Thought the Type1 header
described in https://exiftool.org/TagNames/Samsung.html somehow didn't apply when
the IFD is present. But yes, I just extracted the preview image successfully from my samples too.
So I agree now that that must have been the reason why the camera operations slowed down when I
zeroed out the whole maker note.

I actually did a test where I zeroed out only one of those sections described in the IFD at a time.
Did not notice any difference in the functionality on the camera. Everything worked as normal.

I also realized that the MN_PRV is about 1368 bytes long and the Kim Miae section is around 2796 bytes.
Both too short to hold a reasonable preview that's displayed on the LCD.
Since the LCD is 230K, even the small images that are displayed when you zoom out to the 9 pics / screen
browsing mode,  are  too big to fit in those sections of the maker note data.

Will continue to investigate.

[Phil Harvey]

The sizes you quote don't agree with my observations.  I see this:

0) Tag 0x0001 "MN_PRV" - either 4000 or 4100 bytes

1) Tag 0x0002 "Kim Miae" - always 7000 bytes

2) Tag 0x0003 "Lee BK" - always 5000 bytes

3) Tag 0x0004 "IPCD" - usually 2000 bytes, but 500 bytes for one model

4) Tag 0x0006 "MN_ADS" - either 100 or 200 bytes

But I just realized you may be talking about the amount of non-zero data, which would make sense, because the data blocks often (usually... always?) contain a huge chunk of zero-byte data at the end.

- Phil