Still active??

[tester0077]

Hi,
I'm interested in the project and was wondering if it is active.
From the looks of things, it seems to be currently based on Linux or Mac OS, while I am on Windows.
My initial project is looking for jason.hpp.
It does not seem to be included, where would I find it?

TIA

[tychonievich]

This is a proof-of-concept implementation, but it remains functional.
I am a Linux user, and don't have a MacOS or Windows build environment of my own. I'm happy to implement changes to run on those platfomrs if you have suggested changes I should make.

How to get json.hpp and the other dependencies are documented in the README. json.hpp is available from https://github.com/nlohmann/json/releases

[tester0077]

My apologies for not 'finding' the link to jason.hpp. I have downloaded it now, but am stalled with the XMP SDK.
Its support for windows seems to have shrunk over the years and, even though I had compiled and used it several rears back, I got away from it, first to Exiv2, and now I am primarily using Exiftool for my work.
In fact, my interest in metadata has lead me to build a front-end for Exiftool along the lines of the now unsupported ExiftoolGUI app. It is still a work in progress right now, though reading data is pretty well functional.
My main interest is really in genealogy and where to save what data of interest for that purpose in the multitude of available locations in the metadata 'jungle' .
This is how I ended up finding your presentation and the github repo.
I will read what is posted on github, as well as try to hook up to FHMWG via linkedin.

[tester0077]

I have now been able to compile and link both the parser and write code and the parser seems to extract data from an image.
the image of the wilted rose from the SDK test images.
But I have not been able to test the writer, because I am unsure how to provide the Jason data to the writer within the IDE.
If I can resolve that issue - I am not at all familiar - yet - with jason - I am very interested in checking and working with this code

[tychonievich]

Glad you got it working!

I'm not familiar with your IDE, so I can't help with how it handles stdin, but you can change the program to import a JSON file instead of using stdin. writer.cpp line 321 is the only line of code that uses stdin and could be changed to use a file name from the command line instead, as e.g.

ifstream jsonfile; // you may need to add "#include <fstream>" at the top of the file
jsonfile.open(argv[3]); // note: also change the argc check to require one more argument
auto j = json::parse(jsonfile); // instead of stdin
jsonfile.close(); // technically not required, but recommended

[tester0077]

Thank you for that information.
I had just been trying to work with the writer and lit looks that under Windows, there will be a number of differences needed.
Presumably delineated by some OS specific code with #if defined( )
What I have found thus far, is the the permissions for the output file are not working to let the writer overwrite it on successive runs, hence I either need to make sure the output file is writable or, I have to delete it before copying the initial file.
The second problem I have run into is that the copyFile routine dos not copy the complete file under Windows.
A third issue I am wondering about, is whether you intend to make this run as either a 32-bit app or 64-bit, or both. There are some differences under Windows.
Meanwhile I will have a look at that json code.

[tychonievich]

Not overwriting a file was intentional, to avoid removing existing metadata. If you really want to be able to change metadata instead of making new images with different metadata, you can disable the does-not-exist checks by changing two lines of code:

1. Remove the "does not exist" check || access(argv[2], F_OK) == 0 (writer.cpp line 294)
2. Remove the "refuse if it exists" flag | O_EXCL (writer.cpp line 278)
   The underlying code is also capable of having only a single image which it reads and changes, but the main function is not coded to allow that useage, again as an intentional safeguard against accidental metadata loss.

I'm surprised about the copyFile problem. It's using basic C standard library routines which I have found to be cross-platform in the past. Happy to add #ifdef ... or #if defined(...) macros have a Windows-specific variant if needed.

The code I wrote intentionally uses only word-size-invariant types like size_t and ptrdiff_t and should work whether compiled for 32- or 64-bit execution. That said, I only tested it in 64-bit mode.

[tester0077]

Some of those decision will obviously very much depend on the intentions/needs if the final app.
In my case, and during the initial test runs, I very often just overwrite the test file to make sure I start with a known case.
I suppose I did not read one of the comments in readme.md closely enough, which said it will remove all FHMWG recognized data. :-)
Now that I have the write working, it seems the round trip of the metadata does confirm something I had wondered about before: the Japanese title. I shows up as "My Image" for both the default and the ja alternative.
There is one big problem for myself under Windows command line terminals. They do not handle anything but plain ASCCI at all. And even the UTF-8 enabled DOS terminal nor a Powershell terminal do much better.
Still, I don't see the expected Japanese sting in any of the other utilities I have, which ought to and normally would show the proper string as UTF-8.
Still something to be sorted out.
Is there a special invocation to save that string as a UTF-8 string, because if I inspect the actual JPG, that field shows as
rdf:Alt
<rdf:li xml:lang="x-default">My Image</rdf:li>
<rdf:li xml:lang="ja">My Image</rdf:li>
</rdf:Alt>

[tychonievich]

I believe I've debugged these issues.

Some of those decision will obviously very much depend on the intentions/needs if the final app.
True. My intention is
The primary purpose of this project is to provide a public-domain code base others may use, modify, or refer to freely in their own implementations of the FHWMG recommendations.

It shows up as "My Image" for both the default and the ja alternative.

XMP recommends that every x-default also have a language-tagged copy, as in

<rdf:li xml:lang="x-default">My Image</rdf:li>
<rdf:li xml:lang="und">My Image</rdf:li>
<rdf:li xml:lang="ja">私の写真</rdf:li>

It seems that the Adobe XMP Toolkit only behaves as expected if this recommendation is followed. I've pushed an edit that enforces following this recommendation. (#2)

Still, I don't see the expected Japanese sting in any of the other utilities I have, which ought to and normally would show the proper string as UTF-8.

The UTF-8 problem is caused when your platform defaults to char meaning signed char instead of unsigned char. I've added the -funsigned-char flag to the compilation instructions in the Makefile, which fixed it on the default-signed platforms I tried it on. (#3)

the copyFile routine dos not copy the complete file under Windows.

I've added more complicated logic to copyFile to handle cases when write returns early. I don't have access to a Windows to see if this has fixed this problem.

[tester0077]

I have downloaded the current files of the project and compiled them again.
The copyFile code still returns early with got = 0x000a0, which then leaves the new copy as an invalid JPG.
For now, I won't chase that issue,

Currently I have only been able to run the 32-bit version.
For the 64-bit version there are a whole lot more changes I would have to implement and I am not really very familiar with building a 32/64-bit compatible console app under Windows.
My usual work is with wxWidgets, which cleverly hides all of those details from me.
For now, I will stick with the 32-bit version
Whatever other changes you have made, seem to work well enough. I have not had a good look at what was necessary, but I am attaching a couple of screenshots to show the original contents of the tags involved as well as the data after an update by writer.
Along with my current version of writer.cpp zipped.
There are also a number of #define's I have to add to the MSVC solution file to make the compile & link work.

![orig-test](https://user-images.githubusercontent.com/9053628/137971167-e429762f-a578-4a12-8bc5-8441450a7372.jpg
writer.zip
)