Imperial Courier V2.0

[Commander McLane]

I've just tested any 1.77 trunk for the first time (rev 5556), and came across the same problem as described above: The main entity of my Imperial Courier is way too dark:

Note that the subentities are not affected.

Checking latest.log, the engine does not complain about my ship's texture. It does complain about the Random Hits clone of the IC and another ship, but not about the impcourier2.oxp variant:

Code: Select all

15:28:29.066 [texture.load.png.error]: ***** A PNG loading error occurred for /Applications/Spiele/oolite-trunk-1/AddOns/RandomHits1.4.12oxp.oxp/Textures/imp_cour_tex.png: bad adaptive filter value.
15:28:32.659 [texture.load.png.error]: ***** A PNG loading error occurred for /Applications/Spiele/oolite-trunk-1/AddOns/s-ships1.oxp/Textures/viper_tex.png: bad adaptive filter value.

So, what shall I do? Try to re-save the PNG, although there's no log entry about it?

Also, this reminds me of the same problem with a dark ship many versions ago, where some glitch in smoothing was responsible. Could this be related?

EDIT: loading and re-saving the PNG with GraphicConverter didn't change anything, and neither did setting the smooth parameter to FALSE. The main entity remains dark.

EDIT2: Strange. I had to re-save both IC-textures, the one in impcourier2.oxp and the one in Random Hits OXP (again: although the one of my ship was never in the log), and now the ship has its correct texture again. Also, after re-saving the Viper texture from S-ships OXP, now the log complains about the Oresrian texture from the same OXP. Why didn't it before?

[Eric Walch]

loading and re-saving the PNG with GraphicConverter didn't change anything, and neither did setting the smooth parameter to FALSE. The main entity remains dark.

The error in trunk about the adaptive filter value is about the interlacing of the graphic. In GraphicConverter, you can disable interlacing before re-saving, and the problem is fixed.
In the original IC oxp are two textures for the IC. The military one is okay, but the other gives the problem. In Random Hits, it should be okay as I fixed this in one of the latest releases.

I see the fix is not mentioned in the readMe, so I don'y know which version it was. It is even possible its in the version I still have to upload.

EDIT : IC texture for Random Hits was fixed in 1.4.14

[Commander McLane]

BTW: is it deliberate that the IC texture in RH doesn't have a unique name, and therefore overrides the texture in impcourier2.oxp, if both are installed?

[Selezen]

I note that all the textures are from oxp's of mine. I had a lot of issues early on with the case of the texture names and folders. Could it be something like that (extension being PNG instead of png, looking for Textures instead of textures etc)?

[Commander McLane]

I note that all the textures are from oxp's of mine. I had a lot of issues early on with the case of the texture names and folders. Could it be something like that (extension being PNG instead of png, looking for Textures instead of textures etc)?

No. As Eric pointed out, the problem is that you saved the PNGs in interlaced mode, while Oolite 1.77 requires them to be sequential. Thus, the fix is to open the PNG in an image editor and to re-save it with the option "Adam7" (for some reason that's what the interlacing algorithm for PNGs is called) turned off.

[Selezen]

Ah, actually that does ring a bell. I was no doubt informed of this some time ago then it dropped out of my addled brain again.

Apologies. See, this is why I stopped doing OXPs.

[Eric Walch]

BTW: is it deliberate that the IC texture in RH doesn't have a unique name

I just think Little Bear did not want to go through the trouble of renaming them all with almost a guarantee that you would screw up some links in the process. I only have been renaming those few textures were I made a change to myself.

And about interlacing:
It is an Oolite bug that is caused by a change in the external libraries that deal with PNG files. For the mac version that library is updated recently. So, when a texture does not load properly, you can insist that this is an Oolite bug and does not has to be fixed inside the oxp.
But, as I think it will not be soon fixed in Oolite (It might even be a bug in the new library) I would change the texture in the oxp.

McLane: A nice visual demo you show at interlaced mode for the working of interlacing in PNG. It clearly shows why it is useful for picture presentation with slow internet connections. And because the compression of interlaced pictures is lower, it is not the ideal choice for something like Oolite.

[Commander McLane]

And because the compression of interlaced pictures is lower, it is not the ideal choice for something like Oolite.

Indeed. The interlaced impcourier_tex was about 340KB. Re-saving brought it down to about 285KB. Although this may in part be because some applications are generally more efficient than others with compressing PNGs.

[Eric Walch]

Yesterday, I noticed that the Wiki still contains a link to a version with a wrong texture. One of the two ships in that version can't load the texture on a mac, since Oolite 1.77 and shows up with a black hull. This problem now also starts to show up with some Linux versions.

Therefor I re-saved the texture in the correct format and uploaded a new version of this OXP to my box account. I also converted the plists to ascii format. You can download it at the wiki as: Imperial Courier 2.1

For window users there is no need to update as this corrects only a bug that is visible on the mac, and some Linux versions.

[Lone_Wolf]

version 2.1 gives a new error with libpng 1.6 :

15:22:45.236 [texture.load.png.warning]: ----- A PNG loading warning occurred for /home/panoramix/.Oolite/AddOns/impcourier2.1.oxp/Textures/imp_cour_tex.png: iCCP: profile 'ICC Profile': 1000000h: invalid rendering intent.

running convert on the 2.1 Textures folder gives the same error.

[Eric Walch]

version 2.1 gives a new error with libpng 1.6 :.

Interesting. The oxp has two similar textures of the two versions. The texture file of the navy version is original 66 KB and the normal one is 311 kB in size. Both with the same resolution. The normal one is saved in interlaced mode. If I open it with Graphic Converter and save it again with interlace=off, I get the a file, that gives no errors with me. When I look in the file info, I see the program added a colorSync profile without asking me. I now re-saved the file with the option to add no ICC color profile. Could you check if that works for you libpng version: icour_engine_tex.png

The colour profile added by my graphic program is: sRGB IEC61966-2.1

I use it for years for a lot of textures, but upgraded it recently. So probably it has new features I have to stay away from in future.

[Lone_Wolf]

installed imp courier 2.1 again, replaced imp_cour_tex.png with the new one, no more errors.

Any idea how to verify which ICC profiles are supported on a linux system ?

[Eric Walch]

Thanks for testing the texture Lone_Wolf. In this case, I don't know if my graphic program wrote the profile wrong, or that libpng-1.6 interprets it wrong. (See also: http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html )

This problem was less serious though than the original one. The original one was an error that prevented the texture from loading. This problem just gave a warning and the texture is loaded and used. The player only notices it when looking in the log.

I now replaced the file with the one that works with you. (The one without a ICC profile). There were only two downloads so I keep the same version number. The other downloader will read this and can re-download the same oxp again.

[Rustem]

Hi all,

Updated this OXP(link).
- Tweaks to shipdata.plist file.
- Added textures file for illumination map.
- Adjusted roles to better suite ship type and function.

[Selezen]

Thanks for doing the update, guys.