With exiftool I could not edit some tags like the result after when I put this line
exiftool logo.jpg -"Photoshop Quality"=""
I get this message
Warning: Sorry, Photoshop is not writable
Nothing to do.
My question . why ? how can i fix this problem ? . also I tried this line
exiftool logo.jpg -all=""
all of tags are removed exception of some like . . . .
File Size
File Type
So at the first did not edit . But in the second code worked ?
"Photoshop Quality" is not the name of a tag, it is the description. Make sure you use the command in exiftool FAQ #2 to figure out the correct name to process. You can also look at the Photoshop Tag page to see more info on the Photoshop tags.
The second command will remove all embedded tags in the file, but some tags are actually properties of the file, not embedded information. FileSize, for example, is the actual size of the file as reported by the underlying OS. FileType is the type of the file. These items can't just be changed on a whim, nor can they be removed.
Related
I have a lot of images (JPG) with some metadata.
I'm interested in these three tags, for example, from one of the images:
[XMP] FlightPitchDegree : 0.734793
[XMP] FlightRollDegree : -1.024403
[XMP] FlightYawDegree : 192.286436
I need to copy these values for each image to the next tags:
Xmp.Camera.Pitch
Xmp.Camera.Roll
Xmp.Camera.Yaw
Mostly for tag editing, I'm using ExifTool, but I can't find commands for copying values between tags inside one file.
I'll be very appreciative of any recommendation.
Best,
Andriy
To copy from one tag to another you would use the redirection feature of the -TagsFromFile option. Basically it would be
exiftool "-TARGETTAG<SOURCETAG" file.xmp
You have the names of the SourceTags (FlightPitchDegree/FlightRollDegree/FlightYawDegree), you just need to figure out the exiftool names of your target tags. I can find CameraPitch/CameraYaw/CameraRoll tags on the DJI Tags page, but those are not XMP tags. The only other place I can find tags with similar names are part of the XMP-Camera group, which are not built into exiftool and you would have to download the pix4d.config file and use the -Config option to include those definitions.
exiftool -config /path/to/pix4d.config "-XMP:Pitch< FlightPitchDegree" "-XMP:Yaw<FlightYawDegree" "-XMP:Roll< FlightRollDegree" file.xmp
The -config option must be the very first option in the command in order to load the definitions.
I'm trying to (ultimately) modify a batch of files but getting stuck in the basics as I try to modify a single file before running a batch command.
If someone could help me troubleshoot the command I'm inputting, that would be fantastic. I'm sure it's something very simple.
Thanks a lot for any help you can provide!
Here's the abbreviated image exif data:
-ExifToolVersion=10.10
-FileName=2018_11_13_1.jpeg
-Directory=.
-FileSize=2.8 MB
-FileModifyDate=2019:07:12 15:40:38-07:00
-FileAccessDate=2019:07:12 15:40:38-07:00
-FileInodeChangeDate=2019:07:23 10:38:02-07:00
-FilePermissions=rw-rw-r--
-FileType=JPEG
-FileTypeExtension=jpg
-MIMEType=image/jpeg
[...]
-ModifyDate=2018:11:13 12:00:53
[...]
-DateTimeOriginal=2018:11:13 12:00:53
-CreateDate=2018:11:13 12:00:53
My current input is: exiftool "-FileModifyDate<$filename00000" ./2018_11_13_1.jpeg
And the error message is:
Warning: No writable tags set from 2018_11_13_1.jpeg
0 image files updated
1 image files unchanged
And the exif data is, of course, unchanged.
I've confirmed that I can write a value to this tag, so there's definitely something going wrong in pulling from the filename.
( Continued from How to compensate for incomplete date/time info in filename )
The problem here is that you are trying to write from a tag named filename00000. If you check the example in the other post, you will see that there is a space after Filename. This sets it apart so that exiftool knows which is a tag name and which is other data.
There is possibly an additional problem here, though. Your filename has an extra number that is not the date. When exiftool tries to write the time stamp from the filename, it is going to end up with a value of "2018:11:13 10:00:00", which might become especially problematic if that last digit hits a value of 3 or more, resulting in a timestamp of "2018:11:13 30:00:00".
I would suggest using exiftool's Advanced Formatting Feature (a fancy way of saying that you can use perl code in the command) to strip the excess data. Something like
exiftool "-FileModifyDate<${filename;s/^(.*\d{4}_\d\d_\d\d).*/$1/} 000000" ./2018_11_13_1.jpeg
Though take note, if the filenames are in any other format, then it would require a different command.
tl;dr question:
What is the actual algorithm doxygen uses to find images referenced to in doxygen comments? And the corollary, what's considered best practice which won't break in future doxygen versions?
Details:
We're trying to institute a policy where any images associated with doxygen comments should be localized to the reference, which means we'll have images distributed throughout the source tree. Obviously, we need to make sure that we refer to the images appropriately and that doxygen can find them to produce the correct documentation.
The doxygen documentation states:
doxygen will look for files in the paths (or files) that you specified after the IMAGE_PATH tag
However, in my tinkering I've come to the conclusion that this doesn't seem strictly correct. Here are some experimental results:
================================================
Experiment
File system configuration:
/full/
path/
doxygen.cfg
to/
this/
header.h
images/
image.png
other/
images/
image.png
The doxygen config file is in the "root" of the tree (i.e., /full/path/) and doxygen is executed from this same folder.header.h references images/image.png located in the same tree (/full/path/to/this). There is an identically named image file located elsewhere in the tree. header.h has the line:
#file html [filename]
reference where [filename] is one of the following:
image.png
images/image.png
./images/image.png
/full/path/to/this/images/image.png
Then I play with the IMAGE_PATH variable.
Case 1:IMAGE_PATH = (i.e., no path defined).
"Wrong" image loaded (other/iamges/image.png)
no image
no image
Correct image loaded
Case 2: IMAGE_PATH = /full/path (path provided to root, but not full path to header file).
Correct image loaded
Correct image loaded
Correct image loaded
Correct image loaded
Case 3: IMAGE_PATH = /full/path/other (path provided to root which does not include the header file).
"Wrong" image loaded (other/iamges/image.png)
"Wrong" image loaded (other/iamges/image.png)
"Wrong" image loaded (other/iamges/image.png)
Correct image loaded
================================================
Inferred Algorithm Properties
Relative paths only work if the relative path is in the tree rooted in a path specified in IMAGE_PATH.
In the case where the image file name can resolve into different images, doxygen appears to pick the one "closest" to the reference.
First thing first... thanks for posting this, I was starting to think I was missing something obvious. Now I know there are at least two of us...
I was attempting to include a picture in a markdown file; this may explain the slightly different results I got. Also, I tested with \image command only. At first I only got a long series of "image not found" warnings, but eventually I reached some consistent positive results suggesting that:
The image is only found when IMAGE_PATH setting points directly to the folder where the image is (no parent folder). The manual slightly hints towards this by suggesting that IMAGE_PATH may ba a collection of paths or files
IMAGE_PATH can be expressed as a full path or relative to the location where DOXYGEN is run
Moreover, in order for the image to be "found", the file name and path should match a part of the actual full name and path of the image
For instance, given a markdown page and an image in the following folders:
/some-path/work/my-page.md
/some-path/work/images/some/more/folders/the-image.png
In order to copy the page while running DOXYGEN in the "work" folder, IMAGE_PATH should be set as one of the following:
/some-path/work/images/some/more/folders/the-image.png
/some-path/work/images/some/more/folders
images/some/more/folders/the-image.png
images/some/more/folders
In all cases, the image can be successfully referenced in the markdown page as either "the-image.png" or "folders/the-image.png", "more/folders/the-image.png" etc. The criteria is the reference matching part of the actual file path and name (while one could expect the image reference to be relative to the markdown file it appears in - this seems wrong).
I say again, these tests were conducted using a markdown file, and it's possible in this case the mechanics be different from the one applicable to images referenced in source files.
In html documentation, images were replaced with the broken image icon.
After two days of trial and error, I found out that the reason was in the set text direction (Project->OUTPUT_TEXT_DIRECTION), it should be None, not LTR. The documentation was carried out in two ways:
#image html my_picture.png
I’m using Doxygen 1.8.10 (on Windows) to generate LaTeX files, and MiKTex 2.9 to generate a PDF. The PDF is functional, but not very pretty. I’ve figured out how to customize the title page (I added graphics and non-default text) and how to get the images into the PDF.
But... how do I change the styling for things such as the color of URLs (which are just text in the Doxygen comments, and then Doxygen turns them into \href items)?
**** I believe I need to change something in the hyperref package’s config or what Doxygen writes to the .tex files, but I’m not sure which approach is right, nor how to do either one...
I’ve created a custom_doxygen.sty file, and assigned it to the LATEX_EXTRA_STYLESHEET. I assume that it’s being picked up by Doxygen because Doxygen is successfully picking up my custom LATEX_HEADER file, which is in the same directory as the custom_doxygen.sty file. But what I don’t know is what to put into the custom_doxygen.sty file?
If I run everything as default (that is, no LATEX_EXTRA_STYLESHEET), the following code gets written to the refman.tex file:
% Hyperlinks (required, but should be loaded last)
\usepackage{ifpdf}
\ifpdf
\usepackage[pdftex,pagebackref=true]{hyperref}
\else
\usepackage[ps2pdf,pagebackref=true]{hyperref}
\fi
\hypersetup{%
colorlinks=true,%
linkcolor=blue,%
citecolor=blue,%
unicode%
}
And what I need is for the “urlcolor” to also be blue (its default in the hyperref package is magenta—an odd choice for sure).
I tried just basically copying what was in the refman.tex file to the custom_doxygen.sty file (and making sure that the custom_doxygen.sty file is assigned to the LATEX_EXTRA_STYLESHEET setting in my Doxyfile) and adding a “urlcolor=blue,%” to the setup section, but there’s no change in the output.
If I manually edit the refman.tex file (that is, I add "citecolor=blue,%" to the \hypersetup) after it's output from Doxygen, and then use the edited file as input to MiKTeX, I get the desired output.
So a workaround could be to just script the desired change and run the script every time. But it would be certainly be better to get Doxygen to write the necessary configuration. Plus, there are other things I want to customize (such as the font of explicit html hrefs), so I'd like to learn how to do things properly.
I have very starnge behavior with doxygen. I have source file named as Float32Add.c, when i try to generate the pdf document using doxygen, the documentation does not appear. When i change the same source file name(.c), for e.g. try.c the documentation inside the source file appears (I didnt modify anything except the src file name). I also verified length of the source file is not a problem. Is there any property thats i can look and it helps. Any help regarding this would be appreciated