On 11 Apr 2007 12:17:13 -0700, "Mark" <news@mail.adsl4less.com> wrote:
>- Re looking at the header in a hex editor and copying it from one to
>the other, apart from the first 16 bytes (where IIRC one byte
>differs), I couldn't see any obvious differences between the normal
>jpgs and the "corrupt" ones.
That "one byte," if it is different - only in the failed jpg - from
several examples of good jpgs is sufficient to prevent Windows from
recognizing it as a jpg file.
Simply put, windows, upon seeing a .jpg extension, reads the file's
header. If is is - in any way incorrect - windows will reject it as a
jpg file and treat it as "unknown file type."
When you earlier said that "the files are there," I must assume that
the file sizes - when compared to good jpgs - are approximately the
same size, in bytes. If that is true and the files are otherwise
undamaged, then 95% of the time corrupted file header info is the
culprit.
--
jimbok
> Simply put, windows, upon seeing a .jpg extension, reads the file's
> header. If is is - in any way incorrect - windows will reject it as a
> jpg file and treat it as "unknown file type."
That may be true for windows, but I'd be surprised if all
applications are similarly fooled. Many times I've tried to view
image files (jpg, gif, etc.) using Irfanview and will see a message
stating that the file extension is incorrect and with an offer to
correctly rename the file. Whether I did or didn't allow renaming,
Irfanview then was always able to display the images. I think that
there's a very good chance that the problem is being caused by
either a defective camera, or perhaps by the camera being controlled
by buggy software. HP's tech. support should probably be contacted
to see if they're aware of anything that may be causing the problem.
But even though there's only a very slim chance that the 9 bad files
will be able to be displayed by Irfanview (and if so, would most
likely be able to resave them without errors), it's a free program
that's very small and can be easily downloaded even using dialup.
On 11 Apr, 21:05, ASAAR <cau...@22.com> wrote:
> On Wed, 11 Apr 2007 15:34:10 -0400, jimbok wrote:
> > Simply put, windows, upon seeing a .jpg extension, reads the file's
> > header. If is is - in any way incorrect - windows will reject it as a
> > jpg file and treat it as "unknown file type."
>
> That may be true for windows, but I'd be surprised if all
> applications are similarly fooled. Many times I've tried to view
> image files (jpg, gif, etc.) using Irfanview and will see a message
> stating that the file extension is incorrect and with an offer to
> correctly rename the file. Whether I did or didn't allow renaming,
> Irfanview then was always able to display the images. I think that
> there's a very good chance that the problem is being caused by
> either a defective camera, or perhaps by the camera being controlled
> by buggy software. HP's tech. support should probably be contacted
> to see if they're aware of anything that may be causing the problem.
> But even though there's only a very slim chance that the 9 bad files
> will be able to be displayed by Irfanview (and if so, would most
> likely be able to resave them without errors), it's a free program
> that's very small and can be easily downloaded even using dialup.
Yes, but as per my OP, I tried irfanview as one the first progs. The
actual error it gives for all 9 images is "Huffman table 0x01 was not
defined".
BTW, I tried "jpeg recovery" and that told me the file header was
corrupt.
I'll review the file header comparison thing. It's going to take a
long time as at first glance, the bytes that differ are different on
all images including those that load fine. I'll need to look closer.
Re calling HP - yes, I might give it a go but I'm not encouraged that
it is now listed as an obsolete camera. Also, last time I contacted
them about the compression settings, they didn't seem to know that the
compression level could even be changed!
> Re calling HP - yes, I might give it a go but I'm not encouraged that
> it is now listed as an obsolete camera. Also, last time I contacted
> them about the compression settings, they didn't seem to know that the
> compression level could even be changed!
Sorry, I intended to mention one thing that plague most company's
tech. support departments but didn't get around to it. When you
*think* that you're speaking with a tech. support specialist, you're
usually speaking with a relatively unknowledgeable, relatively
inexperienced tech. support call screener, who is rarely able to
solve a customer's more difficult problems. It can be frustrating
when after asking a simple question, it becomes obvious that the
tech. support specialist can't answer the simplest question, but
will put you on hold while they search for a manual, only to
eventually read back to you what you already know quite well. You
can't really blame them too much since (depending on the company)
they often have to field questions about a huge number of products.
Not just for cameras, but mp3 players, TVs, CD players, etc. In
other words, everything that the manufacturer sells, and anyone with
enough knowledge and experience to be able to do that job well isn't
likely to be found at the lowest level of a company's tech. support.
What you need to do is to escalate the handling of your call to at
least the next level of support. Sometimes this won't be too
difficult, but other times you'll find a lot of resistance, and
it'll help a lot if you're able to appear to be more knowledgeable
than the support screener, explaining why the simplistic responses
or things-to-check that they'll suggest have either already been
tried, or explain why they aren't applicable to your problem.
You'll occasionally speak with someone that is completely
unreasonable, and it's best to be polite, end the call, and try
again at a later time when you'll probably be connected with another
support specialist that has a better attitude.
On Wed, 11 Apr 2007 16:05:45 -0400, ASAAR <caught@22.com> wrote:
> That may be true for windows, but I'd be surprised if all
>applications are similarly fooled. Many times I've tried to view
>image files (jpg, gif, etc.) using Irfanview and will see a message
>stating that the file extension is incorrect and with an offer to
>correctly rename the file.
Any image viewer/editor that I've ever seen would be fooled.
Virtually every file type contains header info that identifies the
file as a particular type. The reason that Irfanview and a number of
other programs give an "incorrect extension" message it that they read
the file extension and then compare it against the file's header
information. If the header info does not agree with the file's
extension and the program reading it is designed to identify specific
file types by header info, such as Irfanview, then it will identify
the true file type based on the information found in the file's
header.
If the header info was damaged, which can and does occur, then the
file will not be recognized as the correct file type, regardless of
its extension.
That type of identifier must be built into the program being used. It
is neither accidental nor coincidental.
On Wed, 11 Apr 2007 18:06:44 -0400, We wonder what jimbok was
thinking when he wrote:
> If the header info was damaged, which can and does occur, then the
> file will not be recognized as the correct file type, regardless of
> its extension.
You're very good at stating the obvious.
> That type of identifier must be built into the program being used.
> It is neither accidental nor coincidental.
Did you *really* think that I thought that Irvanview's ability to
determine the true file types was accidental and not due to explicit
program code used to do an initial file type verification?
On 11 Apr 2007 13:52:41 -0700, "Mark" <news@mail.adsl4less.com> wrote:
>
>I'll review the file header comparison thing. It's going to take a
>long time as at first glance, the bytes that differ are different on
>all images including those that load fine. I'll need to look closer.
If you go through the effort to do this, compare the first 16 bytes of
several known good jpgs. Identify which of those bytes are identical
in each file. Then check a defective jpg.
Any bytes that differ from those identified (by sector/byte position)
as identical to each other in the good files, are probably corrupt.
If correcting them does not restore the jpg then you probably have
more extensive damages to the file which would render it impractical,
if not impossible to restore.
--
jimbok
On Apr 11, 9:52 pm, "Mark" <n...@mail.adsl4less.com> wrote:
> On 11 Apr, 21:05, ASAAR <cau...@22.com> wrote:
>
> > On Wed, 11 Apr 2007 15:34:10 -0400, jimbok wrote:
> > > Simply put, windows, upon seeing a .jpg extension, reads the file's
> > > header. If is is - in any way incorrect - windows will reject it as a
> > > jpg file and treat it as "unknown file type."
And Photoshop in particular will choke on a JPEG with even the tiniest
defect.
>
> > That may be true for windows, but I'd be surprised if all
> > applications are similarly fooled. Many times I've tried to view
> > image files (jpg, gif, etc.) using Irfanview and will see a message
> > stating that the file extension is incorrect and with an offer to
> > correctly rename the file. Whether I did or didn't allow renaming,
> > Irfanview then was always able to display the images.
That will work if the program understands file headers and the file
has a wrong extention. The problem here is that the file extention is
correct but the file header and very possibly the file contents have
been corrupted somehow.
> Yes, but as per my OP, I tried irfanview as one the first progs. The
> actual error it gives for all 9 images is "Huffman table 0x01 was not
> defined".
OK that is *very* important information. No normal application will be
able to display such a file. It is missing the crucial table to tell
it how to do the initial decompress of the JPEG components. What you
have is a random sequence of compressed bits with no information about
how to interpret it! There may be a fairly simple fix, but I would
need to see a couple of sample files to determine if the fault is
easily repairable (ie if the damage is only to the header).
> BTW, I tried "jpeg recovery" and that told me the file header was
> corrupt.
And it is correct. It requires JPEG wizard tricks to read a damaged
file. I am happy to examine a couple of sample files to determine the
nature of this fault. I have never seen a fault that breaks the
Huffman tables before and I am curious to see exactly what has
happened to it. Usually most errors are in the bulk data after start
of stream.
My instinct given the large number of identical faults you have seen
is that the camera firmware is suspect.
A typical failure rate is more like 1:10000 shots (most digicams can
sometimes glitch in a way that generates a broken JPEG file if
suitably provoked). The main way to corrupt files is by ejecting media
with the power still on and read/write in progress. Press
photographers tend to do this in the heat of the moment when a card
fills and they need to replace it quickly. Windows XP can be unkind to
removable media that is ejected unexpectedly too.
>
> I'll review the file header comparison thing. It's going to take a
> long time as at first glance, the bytes that differ are different on
> all images including those that load fine. I'll need to look closer.
> Re calling HP - yes, I might give it a go but I'm not encouraged that
> it is now listed as an obsolete camera. Also, last time I contacted
> them about the compression settings, they didn't seem to know that the
> compression level could even be changed!- Hide quoted text -
On 11 Apr 2007 13:52:41 -0700, "Mark" <news@mail.adsl4less.com> wrote:
>Yes, but as per my OP, I tried irfanview as one the first progs. The
>actual error it gives for all 9 images is "Huffman table 0x01 was not
>defined".
As I understand it, Huffman tables are used in jpeg compression:
On 12 Apr, 09:10, "Martin Brown" <|||newspam...@nezumi.demon.co.uk>
wrote:
> On Apr 11, 9:52 pm, "Mark" <n...@mail.adsl4less.com> wrote:
>
> > On 11 Apr, 21:05, ASAAR <cau...@22.com> wrote:
>
> > > On Wed, 11 Apr 2007 15:34:10 -0400, jimbok wrote:
> > > > Simply put, windows, upon seeing a .jpg extension, reads the file's
> > > > header. If is is - in any way incorrect - windows will reject it as a
> > > > jpg file and treat it as "unknown file type."
>
> And Photoshop in particular will choke on a JPEG with even the tiniest
> defect.
>
And every other Windows app I can find.
>
>
> > > That may be true for windows, but I'd be surprised if all
> > > applications are similarly fooled. Many times I've tried to view
> > > image files (jpg, gif, etc.) using Irfanview and will see a message
> > > stating that the file extension is incorrect and with an offer to
> > > correctly rename the file. Whether I did or didn't allow renaming,
> > > Irfanview then was always able to display the images.
>
> That will work if the program understands file headers and the file
> has a wrong extention. The problem here is that the file extention is
> correct but the file header and very possibly the file contents have
> been corrupted somehow.
>
> > Yes, but as per my OP, I tried irfanview as one the first progs. The
> > actual error it gives for all 9 images is "Huffman table 0x01 was not
> > defined".
>
> OK that is *very* important information. No normal application will be
> able to display such a file. It is missing the crucial table to tell
> it how to do the initial decompress of the JPEG components. What you
> have is a random sequence of compressed bits with no information about
> how to interpret it! There may be a fairly simple fix, but I would
> need to see a couple of sample files to determine if the fault is
> easily repairable (ie if the damage is only to the header).
I did another test. I took one of the corrupt files, gave it a new
name, and copied it back to the card and then put the card back into
the camera to see if it is readable and.... voila! The camera can read
and enlarge it with no problems whatsoever. (I have since taken a
snapshot of the card, and done a test restore of the card image back
to the card and the camera can indeed read it, so now I'm not worried
about formatting the card and reusing it whilst still investigating
this problem.)
>
> > BTW, I tried "jpeg recovery" and that told me the file header was
> > corrupt.
>
> And it is correct. It requires JPEG wizard tricks to read a damaged
> file. I am happy to examine a couple of sample files to determine the
> nature of this fault. I have never seen a fault that breaks the
> Huffman tables before and I am curious to see exactly what has
> happened to it. Usually most errors are in the bulk data after start
> of stream.
There is indeed something that all the corrupt jpgs seem to have in
common. (OK, I didn;t go through all of them but three randomly
corrupt images had this feature that three randomly chosen ones
didn't.) There a section of data in OK images near the top that is a
big series of zeros. The corrupt ones all seem to data data there. I
did try replacing this "data" with zeros but it didn't fix the
problem.
>
> My instinct given the large number of identical faults you have seen
> is that the camera firmware is suspect.
That would be my guess. It is interesting that the firmware can read
files that no Windows software can. It must be making certain
assumptions about the format that Windows software doesn't / can't.
>
> A typical failure rate is more like 1:10000 shots (most digicams can
> sometimes glitch in a way that generates a broken JPEG file if
> suitably provoked). The main way to corrupt files is by ejecting media
> with the power still on and read/write in progress. Press
> photographers tend to do this in the heat of the moment when a card
> fills and they need to replace it quickly. Windows XP can be unkind to
> removable media that is ejected unexpectedly too.
Agreed. But... in this case, I took a sequence of pictures and I can
state with 100% certainty that I didn't eject the card between or
indeed after them. Also, they are in the middle, not at the end of,
a bigger sequence of images. Strange.
>
>
>
> > I'll review the file header comparison thing. It's going to take a
> > long time as at first glance, the bytes that differ are different on
> > all images including those that load fine. I'll need to look closer.
> > Re calling HP - yes, I might give it a go but I'm not encouraged that
> > it is now listed as an obsolete camera. Also, last time I contacted
> > them about the compression settings, they didn't seem to know that the
> > compression level could even be changed!- Hide quoted text -
>
> That sounds about right for HP support
LOL.
>
> Regards,
> Martin Brown
I'm just about to dash out of the house for a while but I'll email a
couple of them over if that's still OK? Might be tomorrow.
Re: Corrupt JPG Files 
Linear Mode
