[mdlug] C Pointer Problem

Bob bob at starlinephoto.com
Sat Apr 11 12:30:25 EDT 2015


Here's the results I came up with, using Gimp, G'Mic filter plug-in >
Testing > Iain furgussion > Gray Descreen

https://www.dropbox.com/s/6kiqgajojedy8hr/elevator_G-Mic.jpg?dl=0

Might be worth a look

Bob Dion

If you hear of anyone needing a photographer please keep me in mind
Cell 501-525-2183
Starline Photographic
http://starlinephoto.com
http://facebook.com/Starlinephotographic

On 04/11/2015 02:44 AM, A. Zimmer wrote:
> On Fri, 10 Apr 2015 20:40:32 -0400
> Gregory Czerniak <gregczrk at gmail.com> wrote:
>
>> #define peiGetConvKer(image)    (*(imageType**)&(image)->clientData[1])
>>
>>  My guess is
>> that it's finding the address of "image", dereferencing clientData[1]
>> (getting the integer), type-casting this integer as a double imageType
>> pointer, and then de-referencing.  By doing that, you'd end up with a
>> single imageType pointer pointing to whatever that integer value was.
>>
> Thanks for this response.
>
> Your description does make sense, especially when we consider how the
> value is being initially stored, as seen in this macro definition:
>
> #define peiSetConvKer(image,ker)	(*(imageType**)&(image)->clientData[1])=(ker)
>
> Here, the variable "ker" is actually a pointer to the "imageType"
> structure and the parentheses around ker, (ker), would mean that
> a pointer to a pointer is being stored in the array.  But the
> clientData[] array stores 32-bit integers, which is compatible with
> pointers on 32-bit systems but differs from the 64-bit pointers
> on 64-bit systems.  This probably contributes to cause of the seg faults.
>
> Anyway, I've decided to abandon the conversion project.  I would have
> to spend way too much time reverse engineering the code to get a better
> understanding of what is actually happening before I could even begin
> to refactor.  Since I can always boot into a 32-bit system using a USB disk,
> such as Gentoo LiveDVD, I can still use the program whenever I need it.
>
> It would be nice to have a pure 64-bit version, however,  The program,
> called peiHalfTone, is used to completely automate the process of
> descreening grayscale digital images and its results are the best I've
> seen not only in the open source Linux world but anywhere else as well.
>
> In case you may be interested, I have posted an example of its
> performance.
>
> An original image containing a very obtrusive halftone pattern
> is shown here:
>
> http://s16.postimg.org/5f9435xmt/elevator_orig.jpg
>
> After processing with peiHalfTone, the result is shown
> here:
>
> http://s10.postimg.org/ov8k02eeh/elevator_conv.jpg
>
> Notice how the halftone pattern is virtually eliminated with
> all frequency measurements being done automatically.
>
> As a comparison, processing with a custom FFT frequency mask
> that I hand-crafted myself is shown next:
>
> http://s12.postimg.org/bxtlgq6ml/elevator_fft.jpg
>
> This last result, which required the manual creation of a frequency
> mask, is close but not as good.  Spending more time would have
> improved the result but using peiHalfTone is nearly instantaneous.
>
> So thanks again for your input.  I think that I have improved my
> ability to understand complex pointer constructions but it's
> doubtful that I'll ever encounter anything similar.  Most people
> seem to prefer more straightforward code.
>
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug



More information about the mdlug mailing list