Re: Possible name confusion about jl2005a vs. jl2005c ?

On Tue, Aug 05, 2008 at 12:23:29PM -0500, kilgota@... wrote:

>
> Yesterday evening, I got the message below from the owner of the camera
> with which the support for the jl2005a camera was developed. It left me
> somewhat nonplussed, but I thought I had better check into the matter. So,
> just now I downloaded libgphoto2-2.4.2 and checked. Indeed, this camera
> library is not listed in configure.ac (extract follows)
>
> GP_CAMLIB([iclick])dnl
> GP_CAMLIB([jamcam])dnl
> GP_CAMLIB([jd11])dnl (next line should have jl2005a and does not)
> GP_CAMLIB([kodak_dc120])dnl
>
> and thus presumably does not compile in libgphoto2-2.4.2.
>
> This is a mistake, no doubt due to the fact that the names are so similar
> between jl2005a and jl2005c. I am not sure at this point who made the
> mistake. It could even have been me. I recall that I got some e-mail some
> time ago which I thought asked me whether to include jl2005c support and
> said no, the compression algorithm for that is not solved, so there is no
> point. I may have misread that mail, or given an answer which seemed clear
> to me in context but was subject to possible misinterpretation on the other
> end.
>
> In any event, the jl2005a library is not to be confused with the jl2005c
> library. The chips supported in the two libraries come from the same
> company and have similar names. At that point, the similarities end.
>
> The actual status of the cameras supported by the two libraries is as
> follows:
>
> Cameras supported by the jl2005a library will work, in all respects, so far
> as I know. Thus, the omission from the released version of libgphoto2 is an
> error.
>
> Cameras supported by the jl2005c library all use a proprietary compression
> algorithm which is not solved and which is particularly complicated and
> nasty. I am working on it, and so are some other people. We all hope
> someday to have the problem solved. In the meantime, the jl2005c cameras
> are all paperweights, because not a single one of them offers an
> uncompressed mode. Therefore, I continue to think it is better not to have
> camlibs/jl2005c to compile by default, as it might lead to confusion by
> some users and lots of messages asking us why the allegedly supported
> cameras do not provide photos.
>
> Sorry that I did not catch this earlier. On July 13, the day of the
> release, I was on a plane en-route to a conference, at which I did not have
> internet access for several days. After the conference, I was on vacation
> until July 29.
>
> I still do not understand what is the problem (mentioned below) about
> compiling the jl2005a driver from the svn tree. All is in order there, as
> far as I know. The only thing I can guess is that Jeronimo means, he went
> and got the release version instead. If so, then indeed there is an
> explanation for his problem.

I have just forgot adding the jl2005a driver to the 2.4 libgphoto2 branch
(which is different from TRUNK).

There was no release from TRUNK yet.

I just merged the jl2005a driver over now.

Ciao, Marcus

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@...
https://lists.sourceforge.net/lists/listinfo/gphoto-devel

[kilgota]

On Tue, 5 Aug 2008, Marcus Meissner wrote:

> On Tue, Aug 05, 2008 at 12:23:29PM -0500, kilgota@... wrote:
>>
>> Yesterday evening, I got the message below from the owner of the camera
>> with which the support for the jl2005a camera was developed. It left me
>> somewhat nonplussed, but I thought I had better check into the matter. So,
>> just now I downloaded libgphoto2-2.4.2 and checked. Indeed, this camera
>> library is not listed in configure.ac (extract follows)
>>
>> GP_CAMLIB([iclick])dnl
>> GP_CAMLIB([jamcam])dnl
>> GP_CAMLIB([jd11])dnl (next line should have jl2005a and does not)
>> GP_CAMLIB([kodak_dc120])dnl
>>
>> and thus presumably does not compile in libgphoto2-2.4.2.
>>
>> This is a mistake, no doubt due to the fact that the names are so similar
>> between jl2005a and jl2005c. I am not sure at this point who made the
>> mistake. It could even have been me. I recall that I got some e-mail some
>> time ago which I thought asked me whether to include jl2005c support and
>> said no, the compression algorithm for that is not solved, so there is no
>> point. I may have misread that mail, or given an answer which seemed clear
>> to me in context but was subject to possible misinterpretation on the other
>> end.
>>
>> In any event, the jl2005a library is not to be confused with the jl2005c
>> library. The chips supported in the two libraries come from the same
>> company and have similar names. At that point, the similarities end.
>>
>> The actual status of the cameras supported by the two libraries is as
>> follows:
>>
>> Cameras supported by the jl2005a library will work, in all respects, so far
>> as I know. Thus, the omission from the released version of libgphoto2 is an
>> error.
>>
>> Cameras supported by the jl2005c library all use a proprietary compression
>> algorithm which is not solved and which is particularly complicated and
>> nasty. I am working on it, and so are some other people. We all hope
>> someday to have the problem solved. In the meantime, the jl2005c cameras
>> are all paperweights, because not a single one of them offers an
>> uncompressed mode. Therefore, I continue to think it is better not to have
>> camlibs/jl2005c to compile by default, as it might lead to confusion by
>> some users and lots of messages asking us why the allegedly supported
>> cameras do not provide photos.
>>
>> Sorry that I did not catch this earlier. On July 13, the day of the
>> release, I was on a plane en-route to a conference, at which I did not have
>> internet access for several days. After the conference, I was on vacation
>> until July 29.
>>
>> I still do not understand what is the problem (mentioned below) about
>> compiling the jl2005a driver from the svn tree. All is in order there, as
>> far as I know. The only thing I can guess is that Jeronimo means, he went
>> and got the release version instead. If so, then indeed there is an
>> explanation for his problem.
>
> I have just forgot adding the jl2005a driver to the 2.4 libgphoto2 branch
> (which is different from TRUNK).
>
> There was no release from TRUNK yet.

(???)

>
> I just merged the jl2005a driver over now.

What exactly is the practical consequence of this "merge"? I guess that I
remain confused.

>
> Ciao, Marcus
>

As to Jeronimo, he has contacted me off-list, and it seems his problem is
solved. Apparently he was not using 2.4.2 after all, and the problem had
nothing to do with this discussion at all. Therefore, I have removed him
from the list of recipients. His message merely alerted me to the need to
check what is happening with 2.4.2 because I _thought_ he might be
using it. And I found a problem.

Theodore Kilgore

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@...
https://lists.sourceforge.net/lists/listinfo/gphoto-devel

[Hubert Figuiere-2]

On Tue, 2008-08-05 at 17:25 -0500, kilgota@... wrote:
> > I have just forgot adding the jl2005a driver to the 2.4 libgphoto2
> branch
> > (which is different from TRUNK).
> >
> > There was no release from TRUNK yet.
>
> (???)

Yes. We branched for 2.4.0, and from that branch Marcus released 2.4.1
and 2.4.2

> > I just merged the jl2005a driver over now.
>
> What exactly is the practical consequence of this "merge"? I guess
> that I
> remain confused.

That mean the driver is in the 2.4.x branch so that one can release
2.4.3 with it.

trunk so far hasn't seen a release because it is a bit a work in
progress, with heavy changes required to address so earlier design
limitations.


Hub


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@...
https://lists.sourceforge.net/lists/listinfo/gphoto-devel

[kilgota]

On Thu, 7 Aug 2008, Hubert Figuiere wrote:

> On Tue, 2008-08-05 at 17:25 -0500, kilgota@... wrote:
>>> I have just forgot adding the jl2005a driver to the 2.4 libgphoto2
>> branch
>>> (which is different from TRUNK).
>>>
>>> There was no release from TRUNK yet.
>>
>> (???)
>
> Yes. We branched for 2.4.0, and from that branch Marcus released 2.4.1
> and 2.4.2
>
>>> I just merged the jl2005a driver over now.
>>
>> What exactly is the practical consequence of this "merge"? I guess
>> that I
>> remain confused.
>
> That mean the driver is in the 2.4.x branch so that one can release
> 2.4.3 with it.
>
> trunk so far hasn't seen a release because it is a bit a work in
> progress, with heavy changes required to address so earlier design
> limitations.
>
>
> Hub
>

Hmmm.

Yes, I see. So I look more closely and I get yet another surprise.

The libgphoto2/ahd_bayer.c file is missing, and, consequently, the most
recent versions of several of my camera libraries, which would call upon
the functions in it, are therefore not present either.

Perhaps it is understandable that I really do not want to look any more
deeply into the code in the 2.4.2 release than I already have?

Let me conclude by just saying the following:

What has occurred is not what I expected.


Theodore Kilgore

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@...
https://lists.sourceforge.net/lists/listinfo/gphoto-devel

On Thu, Aug 07, 2008 at 12:57:01PM -0500, kilgota@... wrote:

>
>
> On Thu, 7 Aug 2008, Hubert Figuiere wrote:
>
> > On Tue, 2008-08-05 at 17:25 -0500, kilgota@... wrote:
> >>> I have just forgot adding the jl2005a driver to the 2.4 libgphoto2
> >> branch
> >>> (which is different from TRUNK).
> >>>
> >>> There was no release from TRUNK yet.
> >>
> >> (???)
> >
> > Yes. We branched for 2.4.0, and from that branch Marcus released 2.4.1
> > and 2.4.2
> >
> >>> I just merged the jl2005a driver over now.
> >>
> >> What exactly is the practical consequence of this "merge"? I guess
> >> that I
> >> remain confused.
> >
> > That mean the driver is in the 2.4.x branch so that one can release
> > 2.4.3 with it.
> >
> > trunk so far hasn't seen a release because it is a bit a work in
> > progress, with heavy changes required to address so earlier design
> > limitations.
> >
> >
> > Hub
> >
>
> Hmmm.
>
> Yes, I see. So I look more closely and I get yet another surprise.
>
> The libgphoto2/ahd_bayer.c file is missing, and, consequently, the most
> recent versions of several of my camera libraries, which would call upon
> the functions in it, are therefore not present either.
>
> Perhaps it is understandable that I really do not want to look any more
> deeply into the code in the 2.4.2 release than I already have?

The 2.4 branch was forked off in July 2007. Everything afterwards is not
in the 2.4.x releases, except when explicitly ported.

This includes for instance the AHD bayer code.

Ciao, Marcus

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@...
https://lists.sourceforge.net/lists/listinfo/gphoto-devel

[kilgota]

On Thu, 7 Aug 2008, Marcus Meissner wrote:

> On Thu, Aug 07, 2008 at 12:57:01PM -0500, kilgota@... wrote:
>>
>>
>> On Thu, 7 Aug 2008, Hubert Figuiere wrote:
>>
>>> On Tue, 2008-08-05 at 17:25 -0500, kilgota@... wrote:
>>>>> I have just forgot adding the jl2005a driver to the 2.4 libgphoto2
>>>> branch
>>>>> (which is different from TRUNK).
>>>>>
>>>>> There was no release from TRUNK yet.
>>>>
>>>> (???)
>>>
>>> Yes. We branched for 2.4.0, and from that branch Marcus released 2.4.1
>>> and 2.4.2
>>>
>>>>> I just merged the jl2005a driver over now.
>>>>
>>>> What exactly is the practical consequence of this "merge"? I guess
>>>> that I
>>>> remain confused.
>>>
>>> That mean the driver is in the 2.4.x branch so that one can release
>>> 2.4.3 with it.
>>>
>>> trunk so far hasn't seen a release because it is a bit a work in
>>> progress, with heavy changes required to address so earlier design
>>> limitations.
>>>
>>>
>>> Hub
>>>
>>
>> Hmmm.
>>
>> Yes, I see. So I look more closely and I get yet another surprise.
>>
>> The libgphoto2/ahd_bayer.c file is missing, and, consequently, the most
>> recent versions of several of my camera libraries, which would call upon
>> the functions in it, are therefore not present either.
>>
>> Perhaps it is understandable that I really do not want to look any more
>> deeply into the code in the 2.4.2 release than I already have?
>
> The 2.4 branch was forked off in July 2007. Everything afterwards is not
> in the 2.4.x releases, except when explicitly ported.
>
> This includes for instance the AHD bayer code.
>
> Ciao, Marcus
>

Thanks, this is a clarifying explanation of what has happened, that
nothing has been put into the "2.4 branch" except what has been
"explicitly ported." I guess I can see more or less what happened, now.

Let me guess:

You were very involved in the infrastructure reforms which are still not
completed. Part of the reason is that such things always take longer than
what is reasonable, and part of it is that you have had simultaneous
demands from your workplace. Therefore, things are not as far along as you
had wished, and you decided that the best thing to do is not to screw with
moving new stuff or changes into libgphoto2/libgphoto2, for fear that
something gets broken. Also, you probably have worried that if you make
one change as a favor to one person, then someone else will come along and
want another. In that regard, the fact that when adding the AHD bayer code
I tried very hard to be minimally disruptive (and, I think, succeeded in
that very well), and even asked for some advice about how to go about
adding the code in a most minimally disruptive manner, would probably be
irrelevant.

If this is what happened, more or less, then I sympathize with your
motivations. However, I guess that you can also understand that the
results have been a bit of a surprise.

Theodore Kilgore

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@...
https://lists.sourceforge.net/lists/listinfo/gphoto-devel

> Thanks, this is a clarifying explanation of what has happened, that nothing
> has been put into the "2.4 branch" except what has been "explicitly
> ported." I guess I can see more or less what happened, now.
>
> Let me guess:
>
> You were very involved in the infrastructure reforms which are still not
> completed. Part of the reason is that such things always take longer than
> what is reasonable, and part of it is that you have had simultaneous
> demands from your workplace. Therefore, things are not as far along as you
> had wished, and you decided that the best thing to do is not to screw with
> moving new stuff or changes into libgphoto2/libgphoto2, for fear that
> something gets broken. Also, you probably have worried that if you make one
> change as a favor to one person, then someone else will come along and want
> another. In that regard, the fact that when adding the AHD bayer code I
> tried very hard to be minimally disruptive (and, I think, succeeded in that
> very well), and even asked for some advice about how to go about adding the
> code in a most minimally disruptive manner, would probably be irrelevant.

I considered this for the libgphoto2 2.4.3 release and I backported
the AHD bayer stuff from mainline.

So it is now available for our users. :)

Ciao, Marcus

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@...
https://lists.sourceforge.net/lists/listinfo/gphoto-devel

[kilgota]

On Mon, 20 Oct 2008, Marcus Meissner wrote:

(snip)

> I considered this for the libgphoto2 2.4.3 release and I backported
> the AHD bayer stuff from mainline.
>
> So it is now available for our users. :)
>
> Ciao, Marcus
>

Great. Has it at this point been tested with some other cameras, too? If
so, I would really like to get some reports about that.

As to the #$%^@ jl2005c compression, there is some progress but nothing
which is quite tangible yet. The algorithm is so complicated that it is a
bad dream.

Theodore Kilgore

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@...
https://lists.sourceforge.net/lists/listinfo/gphoto-devel