AGG palette formatoption requires absolute path

[jmckenna]

Relative paths to the AGG palette file do not work:

OUTPUTFORMAT
    NAME "agg/png24"
    MIMETYPE "image/png; mode=24bit"
    DRIVER "AGG/PNG"
    EXTENSION "png"
    IMAGEMODE "RGB"
    FORMATOPTION "PALETTE_FORCE=TRUE"
    FORMATOPTION "PALETTE=palette.txt"  
END 

causes this error: msImageCreateWithPaletteGD(): Unable to access file. Error opening palette file palette.txt

It should be relative to the location of the mapfile.

[sdlime]

I agree and would have set it up that way if it were straightforward. Problem is that the image handling is basically mapfile independent and I don't have access to the stored path from an image format object. Not sure how best to handle...

Also changing component since this isn't specific to AGG.

Steve

[hobu]

Pushing this forward to 5.2, maybe we can figure out a clean way to deal with it then.

[sdlime]

We'll need to stuff the map path in the image object some place OR pass mapObj's around in places we haven't in the past.

Steve

[sdlime]

Anybody have ideas on how to best address? I see at least three options:

1 - add a new structure member, a pointer back to the parent mapObj to outputFormatObj's 2 - add a new structure member (mappath) to outputFormatObj's to hold the value of mappath from the initializing mapObj 3 - add code to mapfile.c so that mappath is added as a format option in cases where PALETTE= is found.

1 is something we do elsewhere (e.g. layers) and would keep the outputFormatObj in sync with the mapObj and is probably the easiest to implement.

Thoughts?

Steve

[warmerdam]

Steve,

What about changing msSaveImage() to pass the mapObj * down into msSaveImageGD() and msSaveImageGDCtx()? msSaveImageGDAL() already requires the mapObj.

I'm not keen on "back pointers" to the map in objects like the outputFormatObj because they are tricky to keep valid when things are moved around.

[sdlime]

Can certainly try that, thanks for the input.

Steve

[sdlime]

Argh, I don't think that will work. The function that mapscript uses to return an image buffer (e.g. msSaveImageBuffer) also needs the mapObj then. Problem is that it would require a change to the mapscript api to make that happen and I don't want to do that. Not for something this insignificant and not for a 5.x release.

We need to keep those function signatures consistent. I knew this would be a pain so I'm deferring until 5.4.

Steve

[warmerdam]

Steve,

I see that the mapscript imageObj.save() method takes an optional map argument. Why couldn't the getBytes() and getSize() methods on the imageObj also take this as an optional argument? I don't see how that would be break backward compatability. The current msSaveImageBuffer() really doesn't work properly (as far as I can tell) for situations where a map is required - such as saving to geotiff with georeferencing which requires the mapObj.

Looking at the code I'm somewhat horrified at the duplication between the msSaveImage() functions and the msSaveImageBuffer() functions and the fact that one takes a mapObj and one doesn't - for no apparent reason.

With some care for backward compatability (ie. map mapObj an optional argument) I don't see why this couldn't be done at 5.2 without adverse effects on existing scripts.

[sdlime]

I'm not sure devs even know about msSaveImageBuffer(). It always seems to be out of sync with msSaveImage. Would be nice to have one function with file and buffer-based wrappers. I'll look into optional argument solution. I added everything necessary the other night but stopped when I saw the missing argument to msSaveImageBuffer()...

Will shoot for 5.2.

Steve

[sdlime]

Moving to 5.4, no time...

Steve

[tbonfort]

also reported in #2577

[sdlime]

Thomas, is this an issue with the new rendering code?

Steve

[dmorissette]

Moving to 6.0.

[tbonfort]

fixed in r11521 for msSaveImage()

The change is not active for msSaveImageBuffer as that would lead to changes in the mapscript api that I am not willing to take on.

closing this one, mapscript users of msSaveImageBuffer that need the functionality can open a new request/bug if needed