Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Theodore Kilgore
------------------------------
Marcus,

IIRC camlibs/polaroid is yours.

Theodore Kilgore
-------------------------------

On Fri, 16 Sep 2005, Martin wrote:

> It appears to be at least talking with the camera now.

Great.

> I replaced the 2 AAA batteries in the camera and now it is being detected by
> gphoto2 - cool stuff.
>

Ah, so. That was the problem, then? And all of us genius developers were
sending you hunting for library dependencies and the ld.so configuration
file, or was that part of the problem, too? Actually, I was wondering when
the day comes that some distro gets the bright idea of leaving
/usr/local/bin off the executable path, and/or leaves /usr/local/lib off
the library path, on the grounds that "nobody" puts things in the place
where, historically, _all_ locally installed libraries and executables are
supposed to be placed. It may have happened ...

> But the actual files when I use Gimp to view them are very under exposed.
> Is there something else in gphoto2 that will increase the brightness in the
> acquired pictures?

Well, yes and no. It would probably have something to do with the support
library for the particular camera, though, and IIRC we had a camera which
was unknown to us. And since this camera _seemed_ to resemble some other
cameras which were already supported, someone (me) suggested to do some
cut-and-paste in a certain support library and see if anything at all
came out from the camera. Thus, the fact that you are actually getting
photos out of the camera which actually look something like what you took
a picture of is very good luck and means that there is a lot of work that
we do not need to do.

> I don't think the camera is malfunctioning, but then again it maybe. I
> haven't used it in a while, not sure.
> Thanks.
>
> Here is the output various gphoto2 outputs.
>
> [root@oldpc root]# /usr/local/bin/gphoto2 --auto-detect
> Model                          Port
> ----------------------------------------------------------
> Clever CAM 360                 usb:
> Clever CAM 360                 usb:001,017
>
>
> [root@oldpc root]# /usr/local/bin/gphoto2 --abilities
> Abilities for camera             : Clever CAM 360
> Serial port support              : yes
> USB support                      : yes
> Capture choices                  :
>                                : Image
> Configuration support            : no
> Delete files on camera support   : yes
> File preview (thumbnail) support : yes
> File upload support              : no
>
>
> [root@oldpc root]# /usr/local/bin/gphoto2 --list-files
> There are 5 files in folder '/':
> #1     scope0001.ppm                 297 KB  352x288  image/x-portable-pixmap
> #2     scope0002.ppm                 297 KB  352x288  image/x-portable-pixmap
> #3     scope0003.ppm                 297 KB  352x288  image/x-portable-pixmap
> #4     scope0004.ppm                 297 KB  352x288  image/x-portable-pixmap
> #5     scope0005.ppm                 297 KB  352x288  image/x-portable-pixmap
>
>
> [root@oldpc root]# /usr/local/bin/gphoto2 --get-all-files
> Downloading 'scope0001.ppm' from folder '/'...
> Saving file as scope0001.ppm
> Downloading 'scope0002.ppm' from folder '/'...
> Saving file as scope0002.ppm
> Downloading 'scope0003.ppm' from folder '/'...
> Saving file as scope0003.ppm
> Downloading 'scope0004.ppm' from folder '/'...
> Saving file as scope0004.ppm
> Downloading 'scope0005.ppm' from folder '/'...
> Saving file as scope0005.ppm
>
>
>
>
> --
> sane-devel mailing list: [hidden email]
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>            to [hidden email]
>

Nice writeup, thanks. Do we get to look at any pictures?

Theodore Kilgore


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Reply | Threaded
Open this post in threaded view
|

Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Marcus Meissner
> >But the actual files when I use Gimp to view them are very under exposed.
> >Is there something else in gphoto2 that will increase the brightness in
> >the acquired pictures?
>
> Well, yes and no. It would probably have something to do with the support
> library for the particular camera, though, and IIRC we had a camera which
> was unknown to us. And since this camera _seemed_ to resemble some other
> cameras which were already supported, someone (me) suggested to do some
> cut-and-paste in a certain support library and see if anything at all
> came out from the camera. Thus, the fact that you are actually getting
> photos out of the camera which actually look something like what you took
> a picture of is very good luck and means that there is a lot of work that
> we do not need to do.

Correct, the polaroid driver downloads raw bayer data from the camera and
does only some postprocessing. For some cameras we do gamma correction of some
sort, for some we do not.

You can configure it in the camera driver source (pdc640.c) or do it by
hand in GIMP later.

(libgphoto2 itself can never do it as perfect as you would do it yourself.)

Btw, what is the USB ids of this camera?

If you want it changed in the driver, feel free to send a patch or tell me
what to change ;)

Ciao, Marcus


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Reply | Threaded
Open this post in threaded view
|

Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Martin-23
 >> Btw, what is the USB ids of this camera?

[root@oldpc root]# /usr/local/bin/gphoto2 --auto-detect
Model Port
----------------------------------------------------------
Clever CAM 360 usb:
Clever CAM 360 usb:001,017

Is this what you're asking for?
-Martin




--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Hub Figuière-2
Martin wrote:
>>> Btw, what is the USB ids of this camera?
>
> [root@oldpc root]# /usr/local/bin/gphoto2 --auto-detect
> Model Port
> ----------------------------------------------------------
> Clever CAM 360 usb:
> Clever CAM 360 usb:001,017
>
> Is this what you're asking for?


no. these are the device #, specific to the current USB subsystem
change. Will change at next connection.

cat /proc/bus/usb/devices

OR

lsusb -v




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Martin-23
 I got this camera communicating with gphoto2 but the pictures are very under exposed.
When I had my work laptop running Windoze XP, there were proper exposure and clear to view and print.
So I'm not sure why the pictures are low brightness - and also appears to be no color in them either?
Regards,
-Martin

> I installed libgphoto2-2.1.6.
>
> Edited the source file pdc640.c in the directory, libgphoto2-2.1.6/camlibs/polaroid/
> and added the lines,
>
> {"Clever CAM 360", 0x797, 0x8001, {
> jd350e,
> BAYER_TILE_BGGR,
> &jd350e_postprocessing_and_flip,
> "scope%04i.ppm"
> }
> },
>
> which is similar to the lines already there for,
> {"GrandTek ScopeCam", 0x797, 0x801c, {
> jd350e,
> BAYER_TILE_BGGR,
> &jd350e_postprocessing_and_flip,
> "scope%04i.ppm"
> }
> },
>
> and did a make and make install.

Also, here is the output from --> lsusb:

============================
Bus 001 Device 001: ID 0000:0000
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0000
  idProduct          0x0000
  bcdDevice            0.00
  iManufacturer           0
  iProduct                2 USB OHCI Root Hub
  iSerial                 1 c6844000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x40
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               none
        wMaxPacketSize          2
        bInterval             255
  Language IDs: (length=4)
     0000 (null)((null))
 
Bus 001 Device 005: ID 05d8:4002 Ultima Electronics Corp. Lifetec LT9385 Scanner
  Language IDs: none (invalid length string descriptor bf; len=0)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x05d8 Ultima Electronics Corp.
  idProduct          0x4002 Lifetec LT9385 Scanner
  bcdDevice            1.00
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      Remote Wakeup
    MaxPower              496mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize         64
        bInterval               0
  Language IDs: none (invalid length string descriptor bf; len=0)
 
Bus 001 Device 006: ID 0797:8001 Grandtech Semiconductor Corp. SmartCam
string descriptor 1 invalid (1e 03; len=1)
string descriptor 2 invalid (1e 03; len=1)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x0797 Grandtech Semiconductor Corp.
  idProduct          0x8001 SmartCam
  bcdDevice            1.00
  iManufacturer           1
  iProduct                2
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           78
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize         64
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize         64
        bInterval               0
string descriptor 3 invalid (0e 02; len=1)
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              3
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               none
        wMaxPacketSize        960
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize         64
        bInterval               0
string descriptor 4 invalid (0e 02; len=1)
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              4
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               none
        wMaxPacketSize          0
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize         64
        bInterval               0
  Language IDs: (length=4)
     0409 English(US)
[root@oldpc root]#
============================


Hubert Figuiere wrote:
Martin wrote:
  
Btw, what is the USB ids of this camera?
        
[root@oldpc root]# /usr/local/bin/gphoto2 --auto-detect
Model Port
----------------------------------------------------------
Clever CAM 360 usb:
Clever CAM 360 usb:001,017

Is this what you're asking for?
    


no. these are the device #, specific to the current USB subsystem
change. Will change at next connection.

cat /proc/bus/usb/devices

OR

lsusb -v



  

--

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Theodore Kilgore


On Fri, 16 Sep 2005, Martin wrote:

> I got this camera communicating with gphoto2 but the pictures are very under
> exposed.
> When I had my work laptop running Windoze XP, there were proper exposure and
> clear to view and print.
> So I'm not sure why the pictures are low brightness - and also appears to be
> no color in them either?
> Regards,
> -Martin
>

Martin,

As you say that there are problems with the color and brightness, I have
an obvious question:

Since we just got this camera working today, how do you know that the
colors are being processed right, instead of being switched around?

Answer:

You don't, and none of us know, either, because we have not yet seen any
output of photos. Remember, where we are right now is that an educated
guess was made that driver X might support previously-unknown camera Y,
and lo and behold after some source-code cut-and-paste and some
configuration difficulties and library path upgrades and battery
replacement, the camera worked, in the sense that it actually emitted data
and the data could be processed into something recognizable.

One thing which could be going wrong here is the color mapping, at which,
clearly, we were purely guessing. What happens with most cameras (and
it seems to apply here in particular) is that the colors are
arranged in an order like one of the following, in which each capital
letter :

RGRGRG ... all the way across row 0 (until column = width-1 is reached)
GBGBGB ... all the way across row 1

the two-line pattern repeats until the bottom of the photo is reached, at
row = height -1.

This pattern is called RGGB (look at the first two pixels in the two
lines). It is obvious that this fundamental scheme can be done in some
other different ways, for example

GBGBGB ...
RGRGRG ...

which is called GBRG

or

BGBGBG ...
GRGRGR ...

which is called BGGR

and one more permissible variant, which I leave to you to see.

Now, this all goes back to the actual sensing hardware. You have a lens in
front of the camera, and right behind it is a video sensor chip. On the
video sensor chip there are literally width times height number of little
microsensors, in a rectangular array on it. Each physical pixel location
(equal to one tiny microsensor) on the sensor chip behind the lens can
measure only the intensity of the light. The intensity reading gets turned
into a color reading by having a tiny color filter on top of it. Then in
order to get a photo image, the software must provide at each pixel a
triple reading (R,G,B) of which only one is a real reading, and the other
two are some kind of average of nearest neigbors where the color really
was sampled. The arrangement of the color sensors in the rectangular array
on the sensor chip is called a "Bayer array" and to compute the missing
color values at each pixel is called variously "de-Bayering" or
"demosaicing" or "demosaicking" and there exist several methods, ranging
from the obvious to the secret, proprietary, and patented for computing
the missing values.

With this explanation, I think you can judge for yourself what will happen
if for example you treat a photo which was supposed to be GRBG under the
false assumption that it is RGGB or some other pattern. So this could be
the problem. Here, remember that nobody knows yet which setting is
right for your camera, neither any of us, nor you. And nobody is to blame
for that. You, you may recall, had to make a guess at that in order to get
the camera to spit out anything at all.

I think that the quickest way to find out whether this could be the
problem which is causing bad-looking images would be to experiment, and
the best person to do that is yourself, since you have the camera and you
have the source code:

Your config entry says

> Edited the source file pdc640.c in the directory,
libgphoto2-2.1.6/camlibs/polaroid/
> and added the lines,
>
> {"Clever CAM 360", 0x797, 0x8001, {
> jd350e,
> BAYER_TILE_BGGR,
> &jd350e_postprocessing_and_flip,
> "scope%04i.ppm"
> }
> },

so my advice would be to change

BAYER_TILE_BGGR,

to be something else. Try all the possibilities. One of them might offer a
dramatic improvement. The entire list of possibilities is to be seen in
the first few lines of libgphoto2-2.1.6/libgphoto2/bayer.h.

Now, if you do this, remember that you do _not_ need to re-make and
re-install the entire libgphoto2 package. It will suffice if you go into
libgphoto2-2.1.6/camlibs/polaroid, change the one line of source code, and
then do make followed by make install, without leaving the directory. Then
download some photos. Make a directory for yourself called camera/test or
something like that, and create subdirectories RGGB, BRRG, ... and
download the same photos into each after making the appropriate change and
re-installation of camlibs/polaroid. Then look at the photos side by side.

Though I obviously cannot guarantee results, I do hope and I strongly
suspect that one of the listed possibilities will give you a dramatic
improvement.

Theodore Kilgore


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Marcus Meissner-4
In reply to this post by Martin-23
On Fri, Sep 16, 2005 at 11:01:41PM -0400, Martin wrote:
> I got this camera communicating with gphoto2 but the pictures are very
> under exposed.
> When I had my work laptop running Windoze XP, there were proper exposure
> and clear to view and print.
> So I'm not sure why the pictures are low brightness - and also appears
> to be no color in them either?

The images come from the camera without processing and need to
postprocessed by the software.

libgphoto2 does that ... but very rudimentary.

Is there no color? Or bad color (color channels flipped)?

Ciao, Marcus


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Martin-23
In reply to this post by Theodore Kilgore
I realize that all of this is guessing experimental work, and so I
greatly appreciate all of your input, ideas and suggestions.
This is what the greater open source community is all about.
I have a learned a lot from this discussion group that I never knew
before. So keep up the good open source work and effort, ladies and
gentlemen.

I'll keep trying different combinations and see what I come up with.
Thank you again.
-Martin



--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Theodore Kilgore


On Sat, 17 Sep 2005, Martin wrote:

> I realize that all of this is guessing experimental work, and so I greatly
> appreciate all of your input, ideas and suggestions.
> This is what the greater open source community is all about.
> I have a learned a lot from this discussion group that I never knew before.
> So keep up the good open source work and effort, ladies and gentlemen.
>
> I'll keep trying different combinations and see what I come up with.
> Thank you again.
> -Martin
>
>

Martin,

It should not be difficult to do this. Merely change one line of the
config data for your camera and see what happens after each change. There
are a total of eight possibilities in theory, but in practice I do not
expect that your camera presents data which is interlaced. This cuts down
the possibilities to four. To save you a minor amount of time and
inconvenience, I reproduce the list in bayer.h:

typedef enum {
         BAYER_TILE_RGGB = 0,
         BAYER_TILE_GRBG = 1,
         BAYER_TILE_BGGR = 2,
         BAYER_TILE_GBRG = 3,
         BAYER_TILE_RGGB_INTERLACED = 4,         /* scanline order:
R1,G1,R2,G2,.
..,G1,B1,G2,B2,... */
         BAYER_TILE_GRBG_INTERLACED = 5,
         BAYER_TILE_BGGR_INTERLACED = 6,
         BAYER_TILE_GBRG_INTERLACED = 7,
} BayerTile;

Your config data used one of these; IIRC it was the first one in the list.
So you ought to test the others.

Again, you do _not_ need to re-install the entire libgphoto2 in order to
test this. Just go into camlibs/polaroid, make the change, save the one
file which was thus affected, and then right from there do make and make
install, which will update _only_ the binaries affected by a change in
that directory and nothing else and will finish within seconds.

Then download some photos. Then change the line again, re-install,
download the photos again. Then again this cycle, and then again. It makes
the procedure to go faster if you open two or three windows. The way I
would do this is to open one window to camlibs/polaroid and open pdc640.c
in my favorite editor. Make the change (refer to the list above if you
need to), and _save_ the file (Do not exit from the editor, do not close
the window). The next window should be open to camlibs/polaroid, too, and
there you need to be root in order to do the make install. So, after you
make the change of one line, move to window number two and do make
install. The third window should be open to something like
camera/bayer_tests (or whatever you want to call it). There, you can
create four subdirectories called RGGB, GRBG, BGGR, GBRG, and for each
choice of color "tiling" download the photos into the correct directory.
With a standard installation, this will occur if you cd _into_ the
relevant directory and run gphoto2 -P.  Then when you finished you can
look at all four directories and compare the same photos, done four ways.
It takes only a few minutes.

And thanks for sticking around to help until the job is finished. If
people do not contact us and tell us about their new cameras and even if
they do that and then do not help us to follow through, then we cannot add
their cameras to the supported list. So by doing this you, too, are part
of the open source community which you mentioned.


Theodore Kilgore



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Reply | Threaded
Open this post in threaded view
|

Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Theodore Kilgore
In reply to this post by Theodore Kilgore
Martin,

Thanks for letting us know that the photo was mirrored, and thanks
for sending me the raw version of the photo.  It came out pretty
much the same as it should for me, after I did the following special steps
while converting to PPM format:

Vertical flip (byte-reversal of entire image)

horizontal flip (byte-reversal of each individual row)


and after this I used BAYER_TILE_GBRG

and got a decent photo with the colors only slightly off from the scanned
image. 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"
  }
},

and then it might come out right with the color correction routines which
are built in the trust350fs_postprocessing routine.

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.

Theodore Kilgore


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
Reply | Threaded
Open this post in threaded view
|

Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Martin-23
He are my testing results (see attached jpg file).

- still mirrored
- looks more grainy

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.

Thanks for your efforts.
-Martin


[hidden email] wrote:
Martin,

Thanks for letting us know that the photo was mirrored, and thanks for sending me the raw version of the photo.  It came out pretty much the same as it should for me, after I did the following special steps while converting to PPM format:

Vertical flip (byte-reversal of entire image)

horizontal flip (byte-reversal of each individual row)


and after this I used BAYER_TILE_GBRG

and got a decent photo with the colors only slightly off from the scanned image. 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"
     }
},

and then it might come out right with the color correction routines which are built in the trust350fs_postprocessing routine.

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.

Theodore Kilgore


--

scope0002.jpg (30K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

Theodore Kilgore


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


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Gphoto-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gphoto-devel