Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Digital Photography > Digital photo question

Reply
Thread Tools

Digital photo question

 
 
Mayayana
Guest
Posts: n/a
 
      01-08-2013
| Other photos which I had processed through PS Elements 3 (I know it is old
| but it does what little I need to do so can't see why I should buy a more
| upto date version). On these the EXIF data had disappeared. I checked back
| on the original file and it was there.
|
I use Paint Shop Pro 5 for most things. It does what I
need and I found v. 7, when I tried it, to be "overproduced".
PSP5 never saves EXIF data. I also have the latest version
of GIMP. In that I can open a.jpg, completely change the
image, then save it as b.jpg, and by default GIMP will save
the Exif data, even updating it, so that where I had a picture
of a large, colorful kite taken 3 years ago, I now have a big
blue rectangle paintd 5 minutes ago, with the following
nonsensical Exif data:

Make: Leica Camera AG
Model: M9 Digital Camera
Software: GIMP 2.8.0
Date/Time: 2013:01:08 09:23:15
Exposure Time: 200/100000
Focal Length: 50
Width: 5216
Height: 3472
Flash: No

GIMP saved the camera data but updated the date/time/thumbnail!


 
Reply With Quote
 
 
 
 
Mayayana
Guest
Posts: n/a
 
      01-08-2013
| Get exiftool and get an accurate look at the metadata.
| GIMP changes exactly the dates that it should change,
| and does not change the dates that it should not change.

| I used both GIMP 2.6.11 and 2.9.1 (a development
| version) to edit a JPEG file. Using "exiftool -G -s
| file_name.jpg" these metadata tags were the same in the
| original and in both of the edited versions:

| Source Tag Label Tag Value
| ============ ====================== ======================
| [EXIF] Model NIKON D4
| [EXIF] DateTimeOriginal 2012:12:25 20:09:49
| [EXIF] CreateDate 2012:12:25 20:09:49
| [MakerNotes] PowerUpTime 2012:03:30 03:24:03
| [XMP] CreatorTool NIKON D4 Ver.1.00
| [Composite] SubSecCreateDate 2012:12:25 20:09:49.60
| [Composite] SubSecDateTimeOriginal 2012:12:25 20:09:49.60
|
| These tags were changed from the original to the edited image:
|
| Source Tag Label Tag Value
| ============ ====================== ======================
| [File] FileModifyDate 2013:01:08 05:50:47-09:00
| [EXIF] Software GIMP 2.6.11
| [EXIF] ModifyDate 2013:01:08 05:50:39
| [Composite] SubSecModifyDate 2013:01:08 05:50:39.60
|
| As you can see, if your software actually looks for the right
| date it will in fact show you the right information when GIMP
| was the editor.
|

I see. Yes, you're right. I was looking at Date Last Modified
(Exif tag # H132), not the original time the picture was
taken. So for the OP that's not a problem. But my point was
not that the date was lost. Rather, it's an example of the
limitations with Exif data. The image was not modified today,
nor was it "taken" 3 years ago. Neither date should have been
retained. The Exif data shouldn't have been retained. It's not a
photo at all. It's an image of a blue rectangle, created about
30 minute ago.

If I were using GIMP on a regular basis I would disable all
the defaults for saving files and not save Exif data by default.
My blue rectangle still retains the date taken, camera model,
etc., which is all false. The only thing my blue rectangle has
in common with the original photo is that I reused the same
GIMP sub-window with the photo loaded to paint the blue
rectangle in. I didn't even save the file with the same name,
yet GIMP defaults to re-inserting the original Exif tags.


 
Reply With Quote
 
 
 
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      01-10-2013
Gerrit <(E-Mail Removed)> wrote:

> Just an example of where things can and do go wrong:


> The other day I sorted out about 1400 pictures for a photobook. I copied
> them into a new folder and renumbered them from 1 through 1400 (odd) in
> approximate date order (they were taken on several different cameras). I
> then had to import them into some photobook software so that they would be
> available to use in the book I am going to make. The photobook software
> allows you to sort the photos by file name or by date taken (from the EXIF
> data no doubt). When I told it to sort by file name it came up with the
> following (in order from 1) 1, 11, 111,1111, 12, 121, 1121, .. etc.
> Obviously the program just sorts by ASCI.


Which is perfectly sensible.

$ perl -e 'for $i (1 .. 999) { printf "mv %d %04d\n", $i, $i }' > CMD
$ sh CMD
$

Fixed. Now 1 2 3 ... 10 ... 100 ... 999 1000 1001 ... 1400 is
0001 0002 0003 ... 0010 ... 0100 ... 0999 1000 1001 ... 1400.

Easy as apple pie.

> That is pretty useless. So I tried
> a sort by date taken. The order it then presented the photos in was
> horrendous, so I checked the EXIF data and found that that was all over the
> place. The worst were some photos which had no date taken. Some which were
> taken within 5 minutes of each other on two different cameras had the EXIF
> date 10 days out. (yes I checked the cameras and they were 30 minutes out)


You did something wrong then between setting up the cameras
and after the copy. Check your software.

> Other photos which I had processed through PS Elements 3 (I know it is old
> but it does what little I need to do so can't see why I should buy a more
> upto date version). On these the EXIF data had disappeared. I checked back
> on the original file and it was there.


So PSE3 did kill your EXIF data?

-Wolfgang
 
Reply With Quote
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      01-10-2013
Floyd L. Davidson <(E-Mail Removed)> wrote:
> Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:


[EXIF]

>>(and how much dead space containing wannabe uninitialised random data)


> And just how important is that?


Very important if you don't know how to program properly
and don't want to do the right thing (parse the data as per
the spec).

-Wolfgang
 
Reply With Quote
 
Martin Brown
Guest
Posts: n/a
 
      01-11-2013
On 10/01/2013 23:12, Wolfgang Weisselberg wrote:
> Floyd L. Davidson <(E-Mail Removed)> wrote:
>> Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:

>
> [EXIF]
>
>>> (and how much dead space containing wannabe uninitialised random data)

>
>> And just how important is that?

>
> Very important if you don't know how to program properly
> and don't want to do the right thing (parse the data as per
> the spec).


Believe me if the media has been trashed by someone ejecting it during a
write you need all the clues you can get. Having some moronic cowboy
coder leaving chunks of random valid JPEG header inside dead space is
extremely unhelpful. Certain mainstream "data recovery" packages will
completely trash the media whilst doing their idea of restoring files
after they encounter a valid start of JPEG Image inside dead space.

Once that has occurred you are really struggling to undo it from that
point on. I should add that no reputable data recovery software should
ever modify the original media. The first step should always be to take
a forensic bitwise identical copy onto another disk and work on that.

Unfortunately best practice is not always followed.

--
Regards,
Martin Brown
 
Reply With Quote
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      01-20-2013
Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:
> On 10/01/2013 23:12, Wolfgang Weisselberg wrote:
>> Floyd L. Davidson <(E-Mail Removed)> wrote:
>>> Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:


>> [EXIF]


>>>> (and how much dead space containing wannabe uninitialised random data)


>>> And just how important is that?


>> Very important if you don't know how to program properly
>> and don't want to do the right thing (parse the data as per
>> the spec).


> Believe me if the media has been trashed by someone ejecting it during a
> write you need all the clues you can get.


The trick is to stop writing when the door opens which leads
to the medium, not when the medium is ejected.

Even FAT, though pretty bad, isn't that badly designed that
it couldn't survive being interrupted in writing. Same for
the card firmware, if properly done. Unfortunately, properly
costs more money than shoddily. At least in the short run.

> Having some moronic cowboy
> coder leaving chunks of random valid JPEG header inside dead space is
> extremely unhelpful.


Did you ever think about what a "format" in the camera does to a
card and the random valid JPEG headers all over the place?
Hint: No, they don't get overwritten ...

> Certain mainstream "data recovery" packages will
> completely trash the media whilst doing their idea of restoring files
> after they encounter a valid start of JPEG Image inside dead space.


That's where you can stick your "moronic cowboy coder" label
to.


> Once that has occurred you are really struggling to undo it from that
> point on.


Add to that that you should only ever work on a copy when
trying to restore such files ... and every program that does
recovery like that should tell you so in no uncertain terms!
Unless it's done by "moronic cowboy coders", or only for
people who happen to know what they do (i.e. anything but
mainstream!).

> I should add that no reputable data recovery software should
> ever modify the original media.


How does a program know it's the original media and not an
identical copy?

> The first step should always be to take
> a forensic bitwise identical copy onto another disk and work on that.


> Unfortunately best practice is not always followed.


So let's all drive with no more than 4 mph, because passengers
may not wear seat belts, drivers or mechanics may disable
airbags and jaywalkers try to suicide by running over in front
of cars.

-Wolfgang
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"rec.photo.digital.txt" and "rec.photo.digital.dat" Filter DataUpdated and Posted SMS 斯蒂文• 夏 Digital Photography 1 11-26-2007 04:29 PM
Labelling prints in galleries: "photo" vs "digital photo" vs "digital manipulation"... Alan Justice Digital Photography 2 06-08-2005 03:10 PM
Re: goodbye rec.photo.digital -hello rec.photo.digital.slr-systems? Woodchuck Bill Digital Photography 36 10-30-2004 11:50 PM
Re: goodbye rec.photo.digital -hello rec.photo.digital.slr-systems? Woodchuck Bill Digital Photography 15 10-27-2004 04:29 AM
Digital Photography RFD: rec.photo.digital.slr vs rec.photo.digital.slr-systems? Lionel Digital Photography 16 09-17-2004 12:48 PM



Advertisments