Hi--

I've have a bunch of Canon CRW files from a PowerShot S70 with 640x480 JPGFromRaw images. I've generated new, larger JPG's that I want to embed into the CRW files. I'm having trouble with it, though, and the Canon viewer, ZoomBrowser (ZB), isn't recognizing the new file fully.

The commands I'm using (in Windows) are:

Bigger problem is that my results are variable depending on the order of the steps:

1) If I just write the ThumbnailImage, everything works fine
2) If I just write the JPGFromRaw, ZB recognizes the file and can convert the RAW, but it does not use the JPGFromRaw image for viewing
3) Same results as #2 if I write the JPGFromRaw and then the ThumbnailImage
4) If I write the ThumbnailImage and then the JPGFromRaw, then the file is corrupted, ZB doesn't recognize it, and it can't convert the RAW.

I tried using the -F option in case it was a MakerNotes offset, but the results are the same.

I really don't know how to troubleshoot any further myself, so I'm hoping for some collective help.

I'm using the latest release (7.51)

Thanks--

Greg

Professional golf gives you the opportunity to play a game you love, to earn big money doing it, and to possibly write your name in the pages of golfing history. As a professional golfer your place of business will be the golf course and the practice range. You won't be stuck behind a desk or in an office cubicle, and your job description - well, you get to write that yourself. You will share the game with other players who love it as well. As you travel from tournament to tournament, your competitors will become your friends. Together you will see the world and share a game with a legendary heritage So choosing a club which is fit you is very important. I suggest you could have a look at the www.golforderonline.com

Actually, my PowerShot (S70) does both. It writes a separate THM and embeds the ThumbnailImage in the CRW. Don't know why it does that, but I figured all this out while I was trying to figure out what utilities use the embedded, and which use the THM.

You say "...if the JPGFromRaw is the wrong size...". I got the impression from the documentation that ExifTool was capable of resizing the ThumbnailImage and JPGFromRaw fields. I've stepped back and tried to use a 640x480 image instead of a higher-res one, and still got the same problems. This way, I shouldn't have to worry about the RawJpgInfo tags.

Let me know if you need sample files...

--Greg

Phil--

First off, I'm using ZoomBrowser 6.11 under WinXP SP3. ActivePerl 5.10.0 Build 1003, ExifTool 7.51

Thanks for your help...I don't have any trouble with the set of commands you provided. The problem comes from trying to write a different file into the JPGFromRaw tag.

Seems to work fine by itself.

Breaks the display of the preview image in ZB. It looks like it takes the thumb and up-rezzes it to the correct pixel size instead. But it will still process the RAW.

Works fine as well, but not very useful.

Breaks the file to the point that the Canon software won't convert the RAW. Same result if I clear the JPGFromRaw tag before writing the JFR image back. But it works fine if, as the 4th command, I write the original thumbnail back.

I've sent you a ZIP file with all the necessary pieces you can use to test this for yourself. The new_jfr.jpg file is 640x480 for now, the same size as the original jfr.jpg. Ultimately, I'd like to embed a bigger JFR, but I'll worry about that when (if) this gets working. Also, is there anyone out there who is successfully writing new JPGFromRaw images into your CRW files and they still work in ZoomBrowser? --Greg

I tried this, and got the same results. The files I was originally playing around with last week when I found these problems didn't have any JFIF tags. But those files had a different YCbCr Subsampling parameter than the Canon originals. So I used an IrfanView plugin that allows you to specify this parameter in the JPG compression, but it didn't make any difference.

--Greg

Well, zoombrowser 6.1.1 wouldn't install for me (it gave an extract error), but the good news is imagebrowser 6.1.1 installed OK and gave me the same symptoms that you were observing.

So I have been able to reproduce the problem and it is solved. This was partly a bug in exiftool and partly a difference with the new utilities. The problem was with data alignment, and the problem only manifested itself for images with an odd number of bytes.

Thanks for the bug report, for the samples to allow me to reproduce this, and for your patience.

I have just released exiftool 7.52 which should solve this for you.

- Phil

Hi Greg,

I did confirm that this worked for the Mac version (I even generated a jpgFromRaw that was a different image from the thumbnail for some of my tests to make it obvious which was displayed).

I'll have another go at installing zoombrowser to see if I can figure this one out. Did you confirm that the jpgFromRaw is displayed if you put the original one back into the file?

- Phil

OK, thanks Greg. Any testing you can do will help. We should be able to figure this one out. I've re-downloaded the ZB 6.1.1 update but it still won't install on my PC running XP service pack2. My next step is to see if I can find another PC to install it on.

I repeated the tests with ImageBrowser, and it worked flawlessly, displaying whatever JpgFromRaw I write without a hiccup (although I admit that I have only tried 640x480 images so far). So the is a ZB-specific quirk.

- Phil

Well, after a couple more wasted hours trying to install the zoombrowser update, I finally got it to work, so I have been able to try a few things myself. The symptoms I observe are different than you: I can't get ZB to display either a thumbnail or a jpgfromraw other than the original. I wonder if we are running a slightly different version of ZB. I'm running 6.1.1.21. Also, I am running Service pack 2, but I don't see how that could affect things.

But after a number of tests, I have narrowed down the possible causes for not displaying the embedded images:

- it isn't the YCbCrSubSampling (but you knew that already)

- it isn't any of the metadata (ie. JFIF)

- it isn't the image dimensions

- it isn't the image file size (I tried adding junk to the end of both the original and your new images to make them the same length, but the Canon ones still worked while the new ones didn't)

- it isn't the image encoding process (all baseline DCT, Huffman)

I could only think of one thing that was left:

- it could be that the quantization tables are different

So I did some specific tests and confirmed that this is the reason. If I copy the quantization tables (DQT segment) and huffman tables (DHT segment) from the Canon image and use them in the new image, then ZB will display this embedded image. Very odd. (Copying either the DQT or the DHT alone doesn't work, they both must be copied.) The only reason I could imagine why this would happen is if Canon intentionally checks for Canon-specific tables and disables display of other embedded images.

Very crazy indeed, but those are the facts.

Unfortunately I know if no utilities that will allow you to use a specific set of quantization tables. I had the bright idea of using ZB to rewrite the JPEG before embedding it, but sadly that didn't work.

So it looks like there is no simple solution to the problem, short of finding or writing a utility to use a specific set of quantization tables in the JPEG transform.

- Phil

Hi,

I didn't dig deeper into this, but... As far I recall, for ZB v6.xx, ZoomBrowser started to use .NET library. Maybe this is somehow related with issue you have. It's just a though.

Greetings,
Bogdan