Skipped content of type multipart/alternative-------------- next part
--------------
A non-text attachment was scrubbed...
Name: scope0002.jpg
Type: image/jpeg
Size: 22853 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050918/a3369399/scope0002-0001.jpg
From kilg...@banach.math.auburn.edu Mon Sep 19 03:05:18 2005
From: kilg...@banach.math.auburn.edu (kilg...@banach.math.auburn.edu)
Date: Mon Sep 19 07:43:46 2005
Subject: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY -
running gphoto2 version 2.1.6
In-Reply-To: <432e0f3c.3080...@ix.netcom.com>
References: <1126541382.6974.8.camel@gk-lex3>
<20050916021523.ga26...@skyscraper.unix9.prv>
<432a3fe9.2040...@ix.netcom.com>
<200509160901.44878.stefan.leich...@camline.com>
<432ac1b4.9050...@ix.netcom.com> <432b0c75.9020...@ix.netcom.com>
<pine.lnx.4.61.0509161341190.11...@banach.math.auburn.edu>
<20050916190906.gd20...@suse.de> <432b1c06.6090...@ix.netcom.com>
<432b1c56.1010...@teaser.fr> <432b8715.9070...@ix.netcom.com>
<pine.lnx.4.61.0509162330460.11...@banach.math.auburn.edu>
<432ca595.9040...@ix.netcom.com>
<pine.lnx.4.61.0509172258420.12...@banach.math.auburn.edu>
<432e0f3c.3080...@ix.netcom.com>
Message-ID: <pine.lnx.4.61.0509182126220.13...@banach.math.auburn.edu>
On Sun, 18 Sep 2005, Martin wrote:
> He are my testing results (see attached jpg file).
>
> - still mirrored
Yecch.
> - looks more grainy
>
That is a side-effect of the colors being wrong.
> 1) The oranges in the actual newspaper turn out as green in the picture (see
> the backwards $ prices).
> 2) The greens in the actual newspaper (see the backwards "5X") turn out ok as
> dark grays in the pic.
> 3) The yellows in the actual newspaper turn out as light grays in the pic.
> 4) The blacks are ok.
> 5) The reds in the actual newspaper turn out as green.
> 6) The blues in the actual newspaper turn out as a gray.
> 7) overall less colour shown in this configuration.
>
as I said:
>> I did the following special steps while
>> converting to PPM format:
>>
>> Vertical flip (byte-reversal of entire image)
>>
Comment: This reverses everything. So the content of each line is
reversed, and the line also gets moved.
>> horizontal flip (byte-reversal of each individual row)
>>
Reverses contents of lines a second time. Uneconomical, perhaps. But I did
it this way for another driver, where 95% of the cameras need the first
operation, and then 5% need the second, afterwards ...
Perhaps what you need to do is to move just the lines, so you might try
one of the other postprocessing routines.
Remark: the order in which I did these does not matter. But after I look
at the source code in camlibs/polaroid it does seem that I am doing this
differently. I did the vertical and horizontal flip first, and the Bayer
routine after. The camlibs/polaroid routines say to do the Bayer routine
first and any vertical and/or horizontal flip after. That _does_ make a
difference.
>>
>> and after this I used BAYER_TILE_GBRG
>>
>> and got a decent photo with the colors only slightly off from the scanned
>> image.
But I did the operations in the opposite order, as I said. Thus, the entry
is still off. I got the photo right, but I did it with my operation
sequence, not with Marcus Meissner's. You need to fit your configuration
to the way he did it, if you want to use his code.
>>Thus I think your entry is a little bit off and probably you should
>> change it to read as follows
>>
>>
>> {"Clever CAM 360", 0x797, 0x8001, {
>> jd350e,
>> BAYER_TILE_GBRG,
>> &trust350fs_postprocessing,
>> "scope%04i.ppm"
>> }
>> },
>>
Well, you need to change it again. Probably it will be better if you work
on the color tiling first, as that comes first in the processing of a
photo, the way it was done here. Probably is BGGR or RGGB, and the
postprocessing is probably the jd350 postprocessing. But again these are
guesses and if I had the camera in my hands it would not take long, I
suspect. I will wager that it should not take you very long, either, just
to apply trial and error to a short list of possibilities. Might also help
you if you go and look at code for the several postprocessing routines.
>> Mind you, I cannot test this directly without a camera; Marcus Meissner is
>> the expert on the polaroid driver. I am not. I can only report what I had
>> to do to get a half-decent-looking photo out of your raw file. The rest is
>> speculation, but this is probably a good place to start.
>>
You can read the above paragraph again, if you are not in too big a
hurry. Just remember that nobody's opinion counts. What matters is whether
it works or not. "The rest is speculation ..."
Cheers,
Theodore Kilgore
