JPEG EXIF replacement on windows at home

On 04/05/2017 16:50, Savageduck wrote:

Lightroom



I hope you realise that you can't mention Adobe products here because
people here anything Adobe, Microsoft, Google, Yahoo or AOL. These are
considered to be institutions and so they would like to destroy them!!!.

I have restrained myself from mentioning anything about Photoshop,
Photoshop Elements or any of the Adobe products for that same reason. I
am a subscriber to Adobe Creative Cloud Package but I can't mention them
here. People are jobless and can't afford anything better. They prefer
Linux, Gimp and IrfanView because they have plenty of time to ****
around with these useless products.

Cross posting to useless NG removed by POTUS.






--
With over 500 million devices now running Windows 10, customer
satisfaction is higher than any previous version of windows.

In article , Mayayana
wrote:


| Exifer is easy to insert exif from another file and easy to fix thumbnails
| after cropping but Exifer only seems to easily edit simple things like the
| date but not the camera or GPS data.
|
I wonder if you'll find anything better. What you
want is something that will display all header fields,
let you edit any, then rebuild the header and reinsert
it. That's not a terribly complex task, but there are
two problems:

1) Since there's no reason for anyone to want to
replace something like camera model or shutter speed
data, there's no reason to provide such a function.

the main reason to change the camera model or exposure info is to
fraudulently enter photo contests.

there are even threads on dpreview where someone states they want to
enter a photo contest but their camera does not qualify for one reason
or another, so they (foolishly) brag that they modified the exif and
then submitted it.

2) Rebuilding the header is a lot more work than editing.
It's easy to replace dates because the number of bytes
doesn't change, so it doesn't require rebuilding the entire
file header. It only requires editing specific bytes.

exif editing utilities do all that *for* you.

So you're looking for something that no one needs
and which is a pain in the neck to carry out.

exif editing utilities exist and it's actually very easy to do.

| For example, if you post a picture on the web that you cropped, if you're
| not familiar with the GPS or thumbnail problem, you end up posting not
only
| the exact location but also the entire picture even though you thought you
| cropped it.
|

If it were me I'd strip all data, saving the image
first to BMP or TIF. (You should never work on
JPGs, anyway. Every edit loses image data.)

editing exif on a jpg does not affect the image data at all.

Then
if you want to add tags use IPTC. EXIF is mainly
intended for technical image data. IPTC is designed
to store general information, like location,
date, description, etc. Since IPTC is used by
journalists, and the structure is simple, I wouldn't
be surprised if there's some kind of simple program
available for adding the comments.

they each have their use.

On 5/4/17 12:07 AM, nospam wrote:
In article , dale
wrote:


I'd like an app that removes EXIF from jpeg files

exiftool can do that (and more):
http://www.sno.phy.queensu.ca/~phil/exiftool/


thanks

--
dale | http://www.dalekelly.org

On 5/4/17 9:06 AM, Paul wrote:
dale wrote:
On 5/3/17 8:25 PM, Paul wrote:
an expert
can detect as being "fake".

I'd like an app that removes EXIF from jpeg files

I'm trying to use open graph protocol and they mentioned, somewhere
... , that EXIF might be a problem

http://ogp.me/

and besides one time,, in a reply not a post, in which I can't quite
remember what I did I can't get a jpeg to show up on a post in facebook

for instance, from the link

meta property="og:image" content="http://example.com/ogp.jpg" /
meta property="og:image:secure_url"
content="https://secure.example.com/ogp.jpg" /
meta property="og:image:type" content="image/jpeg" /
meta property="og:image:width" content="400" /
meta property="og:image:height" content="300" /

the debugger

https://developers.facebook.com/tools/debug/sharing

tells me my image is either too small or too big, but the same image
is "inferred" from my blog

searching tells me there might be problems with my connection, yet my
blog is a subdirectory off my main directory where the index.html file
I am working with is in



Get yourself a hex editor.

On Windows, you can try HxD for example.

The purpose of getting such a tool, is for "visibility", so
you can see how the image formats work.

https://mh-nexus.de/en/hxd/

*******

On disk here, I have rdjpgcom.c. This would be part of the
independent JPEG library.

Instead of 4CC codes, it uses 0xFF and then the Marker value.

In a sample file here, I see FFD8 FFE0, the D8 is Start Of Image,
the E0 is Application Specific Marker.

/*
* JPEG markers consist of one or more 0xFF bytes, followed by a marker
* code byte (which is not an FF). Here are the marker codes of interest
* in this program. (See jdmarker.c for a more complete list.)
*/

#define M_SOF0 0xC0 /* Start Of Frame N */
#define M_SOF1 0xC1 /* N indicates which compression process */
#define M_SOF2 0xC2 /* Only SOF0-SOF2 are now in common use */
#define M_SOF3 0xC3
#define M_SOF5 0xC5 /* NB: codes C4 and CC are NOT SOF markers */
#define M_SOF6 0xC6
#define M_SOF7 0xC7
#define M_SOF9 0xC9
#define M_SOF10 0xCA
#define M_SOF11 0xCB
#define M_SOF13 0xCD
#define M_SOF14 0xCE
#define M_SOF15 0xCF
#define M_SOI 0xD8 /* Start Of Image (beginning of datastream) */
#define M_EOI 0xD9 /* End Of Image (end of datastream) */
#define M_SOS 0xDA /* Start Of Scan (begins compressed data) */
#define M_APP0 0xE0 /* Application-specific marker, type N */
#define M_APP12 0xEC /* (we don't bother to list all 16
APPn's) */
#define M_COM 0xFE /* COMment */

*******

FFD8
FFE0 "JFIF"
FFE1 "Exif"

So it almost looks like JPG packetizes data, and other
informations are stuffed in, willy nilly, with an extension
mechanism (APPn).

In particular, XMP (not in my sample), can now extend past
a max length 64K JPG segment, as a result of messing about
by outfits like Google. They decided to add another image
to the image, a "depth map". Just as examples of how a
venerable format can be made unreadable by modern
software engineers.

I'd hoped, when I saw rdjpgcom.c in my disk search, that
it was going to be able to dump the segments and lengths,
but it doesn't even do that much.

Suffice to say, the Exif is not the only supplier of size
information. JPG existed before Exif or XMP, and survived quite
nicely without it.

So if you wanted a comprehensive tool that could make
sense of any JPG file (without having to read code or
format specifications), forget it.

*******

As for your notion of "too big", there's no such thing.
Images can be resampled to make them fit in a presentation.
Exactly sized bitmaps don't have to be used for everything.
The video card has a very nice hardware scaler, which is
lightning fast. I can't imagine a software standard
in 2017, that doesn't have some sort of resize-on-the-fly
for such a situation. Maybe your "presentation" size is
bigger than the frame defined to hold it ? If so, it
should still present itself, even if portions are cropped.
We've been able to do that for, oh, 30 years or so
(PostScript imaging model).

So what you need to do, is research where these messages
are coming from, and what they might actually mean. The
error messages might not be based on fact, for example.

It's like the bloody OCR I've used in the past, that
says "the image must be between 200DPI and 400DPI",
and I keep seeing that message over and over again.
And I have to bodge the source, to suit the idiots.
It takes me half the day to get the source to fit
within the limit. You mean they couldn't take a
crack at bodging it themselves ? Grrr.

*******

Utility writing, is one of the lowest forms of
software development. The "smart people" write the
kernel or the compilers. That leaves the "bumpkins"
for writing utilities. That's how my software organization
at work was arranged. I developed this model, after
needing to do some data recovery, and the utility writer
had made a useless application for the purpose. I
had to fix it, before I could do emergency data
recovery. I've had a low opinion of utility writers
every since. There's nothing like fixing a program
at source, when you're under time pressure, and
you're not a CS grad. First you fix the program,
then you get to do data recovery.

I got that same feeling when downloading XMP-Toolkit-SDK-CC201412.zip.
The library parts built fine, in no time at all.
But DumpFile was not properly anchored in CMake,
and it took me a week to hand-hack a make file
for it myself (because this was my first CMake
and I don't know how to fix stuff like that).
Then, when it was finished (yes, it compiled and
linked properly), the output was "pure crap". Now,
why do I have such a low opinion of software, and
the "developer hierarchy" where the bumpkin writes
the user-facing utility :-) A week of effort, wasted.

Paul

gonna have to check back on this, after say 25 years of knowing about
hex editors I never took it up, what I would prefer is an editor that
displays native stuff in a native order then leaves the interpretation
to open/save development

anyways, thanks

--
dale | http://www.dalekelly.org

"dale" wrote

|
| I'd like an app that removes EXIF from jpeg files
|

http://www.jsware.net/jsware/scrfiles.php5#jpginf

Included are scripts to extract JPG info. One of them
is a simple VBScript that will remove all EXIF from all
files in a folder you drop onto the script. No need
to use half-baked command line tools.

In article , Mayayana
wrote:

| I'd like an app that removes EXIF from jpeg files

http://www.jsware.net/jsware/scrfiles.php5#jpginf

Included are scripts to extract JPG info. One of them
is a simple VBScript that will remove all EXIF from all
files in a folder you drop onto the script. No need
to use half-baked command line tools.

exiftool is not half baked.

exiftool is the standard to which others are compared.

"nospam" wrote

| exiftool is not half baked.
| exiftool is the standard to which others are compared.

That may be your opinion. I don't compare
anything if the author can't even be bothered
to make a UI front-end. There's no excuse
for command-line-only. It's half-baked. But if
you don't mind the tedium of typing unnecessarily
in console windows then knock yourself out.
You can probably find a DOS-based file manager,
too. Then crank up the old Victrola and you'll be
off to the races.

Mayayana wrote:
"dale" wrote

|
| I'd like an app that removes EXIF from jpeg files
|

http://www.jsware.net/jsware/scrfiles.php5#jpginf

Included are scripts to extract JPG info. One of them
is a simple VBScript that will remove all EXIF from all
files in a folder you drop onto the script. No need
to use half-baked command line tools.

Exiftool was one of the first. And the author
of it, went the extra mile, compared to other
developers. That's why the tool has a following,
because people respect the effort that has gone into
maintaining it.

When Adobe did their XMP SDK as a counter-example,
the utilities that came with it, why, these
would be "utilities you wouldn't let out of
your lab". That's how bad the examples were.
When you see that, that's a counter-example
to "developers who care". So when a developer
takes the time to do it right, it "looks
all that much better than the competition".

Paul

"Paul" wrote

| Exiftool was one of the first. And the author
| of it, went the extra mile, compared to other
| developers.

But no UI. That's not doing it right in my book.
The problem is that every time this question
comes up people ooh and aah over Exiftool.
And there's still no simple, easy, intuitive tool
out there. If people didn't settle for half-baked
then someone might have made a finished product
by now. And people who want to live in 1985
typing in console windows could have those
tools, if that's what they want.

I'm not questioning whether it works. DOS also
works. But it's not a convenient, efficient tool to
use.

In article , Mayayana
wrote:


| exiftool is not half baked.
| exiftool is the standard to which others are compared.

That may be your opinion.

it's not an opinion.

exiftool is demonstrably the most advanced and most sophisticated exif
utility around.

nothing else comes remotely close to what it can do.

its list of features and capabilities is mind-boggling.

I don't compare
anything if the author can't even be bothered
to make a UI front-end.

that's funny, coming from someone who despises apple.

the original mac didn't have a command line, so by your metric, the mac
was fully baked whereas everything else was not. is that actually the
position you want to take? that would be very inconsistent with your
anti-apple views.

in any event, the command line *is* a ui, just not a graphical one.

there are third party graphical ui front ends for exiftool, with links
to them on the exiftool site.

There's no excuse
for command-line-only.

tell that to microsoft, google, apple, linux developers and many others.

not everything needs a gui.

It's half-baked. But if
you don't mind the tedium of typing unnecessarily
in console windows then knock yourself out.

very little typing is needed and since terminal supports drag/drop, no
file manager is needed either.

You can probably find a DOS-based file manager,
too.

no need.

Then crank up the old Victrola and you'll be
off to the races.

easier to stream from one of the various music services. bigger library
too.

In article , Mayayana
wrote:


| Exiftool was one of the first. And the author
| of it, went the extra mile, compared to other
| developers.

But no UI.

it has a ui.

That's not doing it right in my book.

then maybe it's time to get a new book, one on how to write graphical
user interfaces.

others have already done so, but perhaps yours will be better.

The problem is that every time this question
comes up people ooh and aah over Exiftool.
And there's still no simple, easy, intuitive tool
out there. If people didn't settle for half-baked
then someone might have made a finished product
by now. And people who want to live in 1985
typing in console windows could have those
tools, if that's what they want.

says the person who still runs windows xp.

apparently your clock stopped in 2002.

I'm not questioning whether it works. DOS also
works. But it's not a convenient, efficient tool to
use.

neither is windows.

On 5/4/17 7:56 PM, Mayayana wrote:
"dale" wrote

|
| I'd like an app that removes EXIF from jpeg files
|

http://www.jsware.net/jsware/scrfiles.php5#jpginf

Included are scripts to extract JPG info. One of them
is a simple VBScript that will remove all EXIF from all
files in a folder you drop onto the script. No need
to use half-baked command line tools.



thanks

--
dale | http://www.dalekelly.org

On 5/4/17 6:56 PM, dale wrote:
On 5/4/17 9:06 AM, Paul wrote:
dale wrote:
On 5/3/17 8:25 PM, Paul wrote:
an expert
can detect as being "fake".

I'd like an app that removes EXIF from jpeg files

I'm trying to use open graph protocol and they mentioned, somewhere
... , that EXIF might be a problem

http://ogp.me/

and besides one time,, in a reply not a post, in which I can't quite
remember what I did I can't get a jpeg to show up on a post in facebook

for instance, from the link

meta property="og:image" content="http://example.com/ogp.jpg" /
meta property="og:image:secure_url"
content="https://secure.example.com/ogp.jpg" /
meta property="og:image:type" content="image/jpeg" /
meta property="og:image:width" content="400" /
meta property="og:image:height" content="300" /

the debugger

https://developers.facebook.com/tools/debug/sharing

tells me my image is either too small or too big, but the same image
is "inferred" from my blog

searching tells me there might be problems with my connection, yet my
blog is a subdirectory off my main directory where the index.html
file I am working with is in



Get yourself a hex editor.

On Windows, you can try HxD for example.

The purpose of getting such a tool, is for "visibility", so
you can see how the image formats work.

https://mh-nexus.de/en/hxd/

*******

On disk here, I have rdjpgcom.c. This would be part of the
independent JPEG library.

Instead of 4CC codes, it uses 0xFF and then the Marker value.

In a sample file here, I see FFD8 FFE0, the D8 is Start Of Image,
the E0 is Application Specific Marker.

/*
* JPEG markers consist of one or more 0xFF bytes, followed by a marker
* code byte (which is not an FF). Here are the marker codes of
interest
* in this program. (See jdmarker.c for a more complete list.)
*/

#define M_SOF0 0xC0 /* Start Of Frame N */
#define M_SOF1 0xC1 /* N indicates which compression process */
#define M_SOF2 0xC2 /* Only SOF0-SOF2 are now in common use */
#define M_SOF3 0xC3
#define M_SOF5 0xC5 /* NB: codes C4 and CC are NOT SOF markers */
#define M_SOF6 0xC6
#define M_SOF7 0xC7
#define M_SOF9 0xC9
#define M_SOF10 0xCA
#define M_SOF11 0xCB
#define M_SOF13 0xCD
#define M_SOF14 0xCE
#define M_SOF15 0xCF
#define M_SOI 0xD8 /* Start Of Image (beginning of
datastream) */
#define M_EOI 0xD9 /* End Of Image (end of datastream) */
#define M_SOS 0xDA /* Start Of Scan (begins compressed data) */
#define M_APP0 0xE0 /* Application-specific marker, type N */
#define M_APP12 0xEC /* (we don't bother to list all 16
APPn's) */
#define M_COM 0xFE /* COMment */

*******

FFD8
FFE0 "JFIF"
FFE1 "Exif"

So it almost looks like JPG packetizes data, and other
informations are stuffed in, willy nilly, with an extension
mechanism (APPn).

In particular, XMP (not in my sample), can now extend past
a max length 64K JPG segment, as a result of messing about
by outfits like Google. They decided to add another image
to the image, a "depth map". Just as examples of how a
venerable format can be made unreadable by modern
software engineers.

I'd hoped, when I saw rdjpgcom.c in my disk search, that
it was going to be able to dump the segments and lengths,
but it doesn't even do that much.

Suffice to say, the Exif is not the only supplier of size
information. JPG existed before Exif or XMP, and survived quite
nicely without it.

So if you wanted a comprehensive tool that could make
sense of any JPG file (without having to read code or
format specifications), forget it.

*******

As for your notion of "too big", there's no such thing.
Images can be resampled to make them fit in a presentation.
Exactly sized bitmaps don't have to be used for everything.
The video card has a very nice hardware scaler, which is
lightning fast. I can't imagine a software standard
in 2017, that doesn't have some sort of resize-on-the-fly
for such a situation. Maybe your "presentation" size is
bigger than the frame defined to hold it ? If so, it
should still present itself, even if portions are cropped.
We've been able to do that for, oh, 30 years or so
(PostScript imaging model).

So what you need to do, is research where these messages
are coming from, and what they might actually mean. The
error messages might not be based on fact, for example.

It's like the bloody OCR I've used in the past, that
says "the image must be between 200DPI and 400DPI",
and I keep seeing that message over and over again.
And I have to bodge the source, to suit the idiots.
It takes me half the day to get the source to fit
within the limit. You mean they couldn't take a
crack at bodging it themselves ? Grrr.

*******

Utility writing, is one of the lowest forms of
software development. The "smart people" write the
kernel or the compilers. That leaves the "bumpkins"
for writing utilities. That's how my software organization
at work was arranged. I developed this model, after
needing to do some data recovery, and the utility writer
had made a useless application for the purpose. I
had to fix it, before I could do emergency data
recovery. I've had a low opinion of utility writers
every since. There's nothing like fixing a program
at source, when you're under time pressure, and
you're not a CS grad. First you fix the program,
then you get to do data recovery.

I got that same feeling when downloading XMP-Toolkit-SDK-CC201412.zip.
The library parts built fine, in no time at all.
But DumpFile was not properly anchored in CMake,
and it took me a week to hand-hack a make file
for it myself (because this was my first CMake
and I don't know how to fix stuff like that).
Then, when it was finished (yes, it compiled and
linked properly), the output was "pure crap". Now,
why do I have such a low opinion of software, and
the "developer hierarchy" where the bumpkin writes
the user-facing utility :-) A week of effort, wasted.

Paul

gonna have to check back on this, after say 25 years of knowing about
hex editors I never took it up, what I would prefer is an editor that
displays native stuff in a native order then leaves the interpretation
to open/save development

anyways, thanks


guess what I am looking for would be a standard metafile and a standard
metafile reader

--
dale | http://www.dalekelly.org

Mayayana wrote:
"nospam" wrote

| exiftool is not half baked.
| exiftool is the standard to which others are compared.

That may be your opinion. I don't compare
anything if the author can't even be bothered
to make a UI front-end. There's no excuse
for command-line-only. It's half-baked. But if
you don't mind the tedium of typing unnecessarily
in console windows then knock yourself out.
You can probably find a DOS-based file manager,
too. Then crank up the old Victrola and you'll be
off to the races.

There's a picture here, about half way down.

"ExifToolGUI for Windows v5.xx"

http://u88.n24.queensu.ca/~bogdan/

http://u88.n24.queensu.ca/~bogdan/img/gui01.png

Paul

"Paul" wrote

| There's a picture here, about half way down.
|
| "ExifToolGUI for Windows v5.xx"
|
| http://u88.n24.queensu.ca/~bogdan/

Have you tried it? First I had to find the download
for the UI version, in some forum post. Then I had to
download exiftool. (ExifToolGUI doesn't work by itself.
Surprise, surprise.) But downloading exiftool also doesn't
seem to work. Imagine that. I'm starting to get that
nostalgic Linux greasemonkey feeling. Let's open Filemon
and see what ExifToolGUI is trying to do.

I finally figured out it would work if I download the
Windows compiled exiftool, put it in the same folder
*and* rename it, removing the bizarre (-k) thing that's
part of the name. Piece of cake. I didn't even have to
create a Linux /etc folder and create an INI file from
scratch. We're in business now....

So 99% of the public has just been ruled
out as far as being able to even set up this tool.

OK. Then I open an image. I try to change Panasonic
to Canon. That doesn't seem to work. It looks like maybe
I could remove or import EXIF, but there's no capacity
to just edit fields. Wasn't that what the OP wanted and
what people were saying exiftool will do?

Well, it says I can export EXIF data to TXT. OK, I'll do that.
Woops. Where'd it go? ExifToolGUI just saved the text file
to the folder with the JPG, naming it and saving it without
giving me any choice or even telling me! Is this a 7th grade
science fair project or a Windows program? No matter. I find
the file and edit Panasonic to say Canon. Then I ask it to
re-import the file. Now it shows me a window with lots of
checkboxes. Which things to you want to import? XMP-crs
group? Sure. Heck, import all of them. I don't know what half
these boxes are for, anyway. And there's no explanation
available from the window. Just a mysterious label that says
"Back up: OFF". Those 7th-graders are cute, aren't they?

Now I click.... execute...? Since when are buttons labeled
"execute"? I hope my 7th-grader isn't planning to start a video
of a rocket ship at this point. Wasn't I importing metadata?

Oh, this is fun. ExifTollGUI says the TXT file it just saved
is an unknown file type. It can't import. And isn't this cute...
It shows me the error in monospaced font, ending with
"-END-" Very techie looking. It must be really good
software. I think this kid should get the prize. His project
is much better than the kid who just soaked teeth in orange
soda to show that sugar causes cavities......

How is this better than the simple, clear, usable
interface that IrfanView provides? Do you really
get up in the morning and spend hours entering
long lines into console windows as part of your
organizing your vacation photos? Does anyone do
that? Who? Who types in dozens of long incantations
in console windows, in order to add a note that this
is Uncle Ken's birthday party from 2015? If they don't
then why is exiftool so highly regarded? (If they do
then what the heck is wrong with them?) Lots of
programs can show a listing of metadata. I don't need
to wrestle with gross dysfunction to get that.

I think this is a good example of a class of software --
solidly made OSS. Programs get a reputation as best
of breed because they're technically solid and because
they're open source. Open source is an important aspect.
It makes them part of the club. The programmers hobknob
with the official OSS hotshots.
Exiftool may read more tags than any other tool. But
so what? The usability is ridiculous.

7-Zip is a similar example. It's far more usable than
exiftool, but it's still poorly designed. The main window
is primitive. Drag/drop functionality -- around for 20
years -- is missing. I drop a ZIP to open it and 7-Zip
wants to start a new .7z archive! Starting with a ZIP
file on the Desktop it's a big job just to open the thing.
I have to crawl down through levels of a Win3.1-era
file list window.
Of course, I could make 7-Zip the default and not
have to drop a ZIP into the window, but it doesn't
work well enough for that. Technically, it's so good it
should have long ago replaced all other ZIP programs.
But the usability is so poor that hardly anyone has ever
heard of it.... Except in clubby OSS circles where it gets
the award for best of breed.