Texture Blending or Dithering

[Fern]

Hi,

Thanks to Scott S and Holger Sandmann, I think I have a revised question to ask

Background: I am adding terrain custom textures to an area near North Bay (CYYB) in Canada, in FS2004, using the Resampler of the FS2004 SDK. The cells in the pictures attached are LOD13.

My problem: FS2004, during the month between 17-April-2008 and 18-May-2008 seems to maintain cells still in Hw (snow) while the cells at lower latitudes are already displaying Sp (no snow) textures. The line dividing the area with Hw cells and the area with Sp cells is jagged, irregular along the longitudes and goes up and down latitudes a bit, presumably to make it look more real.

In the area I am working on, the cells still in Hw and the cells already in Sp form a sort of checkerboard, shown in Picture 1, attached, which contains my custom textures.

When showing the default textures for the same area, FS2004 seems to "blend", or "dither" as Scott S said, the textures of Hw(snow) and Sp(no snow) and forms a connection between the Hw and Sp cells which looks realistic and seems to dissolve the checkerboard. Picture 2, attached, shows the same area with the default textures, and comparing the two pictures it is just possible to imagine the portions where the "dithering" appears to takes place in Picture 2.

The two pictures were taken at approximately N46* 16.77' and W79*24.82', North on top. Both pictures are of approximately the same area, for the same date, during the month when there are Hw and Sp textures showing side by side, picture 1 with my custom textures, picture 2 with default textures.

I have added a line at the bottom of the Picture 1 showing the South limit of the area I am working on. The limit to the East is quite obvious for the lack of dithering. To the West I have a big lake, so no dithering is required. To the North everything changes at the same date, so I'm OK there, too.

So, here are the three interconnected questions:

1. How does FS2004 accomplish that dithering, or blending?

2. Is it possible to get custom textures to dither as well? How?

3. To the East of my area, I have Hw and Sp cells that need to blend with the Sp and Hw default. Is it possible to dither there?

(I think I read all the documents of the FS2004 Terrain SDK, Christian Stock text on FS2000/2002 Terrain SDK and a few other texts I found. I didn't find any references to this dithering anywhere except Scott S' remark., but I may have missed something...)

Thanks!

Fern

 

[HolgerSandmann]

Hello Fern,

not that I want to dominate this conversation as well but I just happen to work on the files (for an FSX project in a different area) that enable the "dithering". These are the so-called M-tiles, the .bmp files in \Scenery\World\texture that have *m11*, *m12*, etc. in their names.

Most of the urban and agricultural classes have their own M-tiles while vegetation and barren classes use the generic 900* and 901* series.

You can load the M-tile textures into a photo editing tool and will notice that they consist of eight square binary (black&white) panels .

The process of blending is actually quite complex and clever and it's not described in the SDK so several of us did a bunch of tests and experiments over the years. Below are my notes describing key points of the process:

===========================

* blending of neighboring land class ground texture tiles requires spatial overlap

* land class files use LOD13 raster grid nodes (vertices) as reference locations

* at each node, FS places a ground texture tile in the four adjacent LOD13 raster cells, i.e., a 2x2 set of tiles centered on the node.

* given that each LOD13 grid vertex has an associated land class value, each LOD13 raster cell ends up with four "layers" of ground texture tiles; this creates the required spatial overlap for blending

* which of the layers are used for blending (via the M-tiles) depends on their draw priority value; higher numbers mean higher draw priority. The draw priority values for each unique texture set are hard-coded in the lclookup.bgl file.

* if the four layers of a LOD13 raster cell contain two different classes then FS uses the M-tile of the class with the higher draw priority.

* if the four layers of a LOD13 raster cell contain three different classes then FS uses the M-tiles of the two classes with the highest draw priorities together (!); in areas of overlap of the retained part of a texture the M-tile with the higher draw priority is dominant.

* if the four layers of a LOD13 raster cell contain four different classes then FS uses the M-tiles of the three classes with the highest draw priorities together (!); in areas of overlap of the retained part of a texture the M-tile with the higher draw priority is dominant.

* if the four layers of a LOD13 raster cell are of the same land class then no blending occurs

* if different classes with the same draw priority are blended then the M-tiles of the class to the south or east (relative to the other class) will be dominant along its north and west edges, with the M-tiles of the other class being dominant along the south and east edges.

* M-tiles contain eight sub-panels. Which one gets used is determined by the presence and location of textures of the same class in the neighboring cells. Sub-panels 1 or 2 (counted from the top down) are used if the same class touches one of the corners, sub-panels 3 or 4 are used if the class occupies an edge of a block of cells of the same class, and sub-panels 5, 6, 7, or 8 are used if the class occupies a corner of a block of cells of the same class.

* M-tiles are different from Alpha blending masks in that some of the black and white areas in the eight sub-panels can be either transparent or opaque, depending on where the M-tile is used. While the top two sub-panels always retain (show) the white areas, and the bottom four sub-panels always retain the black areas, the third and fourth sub-panel retain either black or white areas depending on adjacency; if the same-class neighbors are to the north or west then black is retained and if the same-class neighbors are to the south or east then white is retained.

===============================

There you have the answer to your question 1

Questions 2 and 3 can be answered as simply No and No. Sorry, but custom textures, placed as spatially fixed (numbered) textures, can't be dithered between adjacent tiles and not really along outer edges either (but see next paragraph).

The alternatives I see are (1) make a custom seasons file for that area/month or (2) place your photoreal images as VTP2 polys. The second option will allow for Alpha-blending along the transition to the generic tiles but you'll still end up with sharp boundaries inside your coverage area if different seasons are being called (never mind the issue with grid lines showing at mid distances and vertical flipping; bugs inherent to the VTP2 system).

Cheers, Holger

P.S.: one more point about the M-tiles: in FS9 they have some odd coding, which makes it difficult to create custom M-tiles. In FSX this barrier has been removed, which is why I can create custom M-tiles for our replacement land class textures.

 

[Fern]

Seasons File

Hi, Holger

Well, I am very glad you decided to reply! I was hoping you would, as I know you know this stuff. Thanks!!!

For now, from what you said, I believe that the best course of action for me would be to make a "seasons" file that I could incorporate in my North Bay area "Scenery" folder.

I haven't done that before, and I have been digesting a lot of information (more since I entered this reply, so I edited it), so here go a few more questions. I apologise if some of the questions look obvious or trivial.

1. In the case of your Alaska, you used LOD2 (big square) and each "pixel" in your raw bitmaps will cover an LOD10 square, I think. Can I make changes for a smaller square, say, LOD 10 or 9 instead of LOD2?

2. If I do a "Seasons" file just for one month for that area, would it work, or do I have to make all 12, even though the other 11 months seem be OK?

3. Side question: How do you make the airport appear on TmfViewer? (My View/Vector Data/Layers has everything checked)

Once again, thanks, Holger. I hope I am learning this...

Fern

 

[HolgerSandmann]

Hi Fern,

you're very welcome!

1. Sorry, FS9 has its seasons files fixed at LOD2. What I would try is to just start adding season data to the immediate airport area and flood fill, in your image editor, the remaining area with cell value 254, which should make them "transparent". If that works then you don't have to worry about having to come up with full coverage for the entire LOD2 section.

2. Yes, seasons file can contain as little as 1 month. For example, Scott's North America replacement - http://library.avsim.net/esearch.php?CatID=fs2004scen&DLID=94527 - only contains the hard winter months.

3. In FS9 the vector and polygon data are stored in thematic files. For the CYYB area it's LOD5 cell 26x15, and thus file AB926150.bgl (Airport Background polygons), in \Name\scenery, that contains the skirting polys. You can use LWMViewer, AFCAD2, or CellGrid2004 to quickly determine the LOD5 grid ID of a given area.

Cheers, Holger

 

[scott967]

ISTM that more than just m-blending is going on, or maybe I haven't understood the full power of the blending.

the first attachment is my seasons.bgl at N42.788 W-90.987 for season 1, showing the winter/hard winter boundary.

Attachment 2 is the simplified landclass view, it appears that there are LOD13 areas that are dithered along the edge. Is this actually caused by the m-blend?

Attachment 3 is a closeup, with LOD13 cellgrid overlaid. this is the "corner" area circled in red in my seasons file. Again, this seems like more than m-blending, or if it is , that is a pretty powerful tool MS came up with!

I found that using sbuilder and VTP2 polys covering the LOD13 for photoscenery with alpha blend in my textures looked pretty good. the main drawback is the textures have to be placed in world\texture which makes a problem for users.

scott s.
.

 

[Fern]

Seasons file and blending

Hi, Scott and Holger

Gosh, this is pretty interesting stuff.

Scott, I am not competent yet to make much of a comment on your reply except that, first, I am starting to ever-so-slightly understand what you guys are saying (and that is scary) and second, that that blending sure looks very clever, indeed. The line separating your Hw from your Wi, at LOD10 level (very similar to mine), is pretty coarse and, yet, it comes out nicely detailed over the LOD13 cells.

Now, considering what Holger said, I think I see what you mean but I need some help there.

1. I will, then, work with LOD2 for my "Seasons" file, and my cell dimension will end up as LOD10, which is the size of the smallest coloured square in the original Seasons.bgl file anyway. This simplifies my making of the inf files, because I'll just copy yours and adapt the Lat/Lon. That, actualy, is cool.

2. I have Photoshop but I never used the "raw" format before, and I am having some problems with it. The Alaska raw files all appear as black squares. I'll have to work on that a bit.

3. Just to make sure I understood, what you (Holger) are suggesting is that I make a "raw" file that actually only contains the portion I want to modify (the area where I want to force Hw for that month), and make the rest of the image transparent. You are, then, suggesting that the rest of the FS original seasons.bgl colour arrangement might, somehow, "show through", is that it? I can try that... (see number 4)

4. When I create my 257 X 257 bitmap I will have a few pixels with white (to force those to be Hard Winter) and the rest "flood filled with cell value 254". I honestly don't expect you to tell me how to use Photoshop here, of course. (I am guessing that for 254 to be transparent in "raw", that format can only have 8 bits per pixel.) So, I "Edit Colour" (or the Photoshop equivalent), enter "254" and flood fill, is that it?

5. Finally for today, this process for creating a custom seasons file only works with "raw", eh? No chance that it would work with "tga with alpha" or some other format with which I am much more familiar?...

Thanks!

F

 

[HolgerSandmann]

Hi guys,

it's interesting stuff indeed, and very much "on the edge" in that it's poorly documented and hardly used by others. Christian, Scott, and myself are the only ones I know of who have published custom seasons files, and Allen Kriesman (Ultimate Terrain), Arnaud Clère (France landclass), and yours truly the only ones who have published custom M-tiles.

Scott, the FS default M-tiles have pretty wild shapes, with "islands", "peninsulae", and curvy outlines, which makes it look as if the dithering extends more than just a single LOD13 cell (which, in fact, it does, because it's always a 2x2 cell block that's involved). I'm almost done with creating some 160 custom M-tiles for the first FTX product and I also did the custom seasons file for that (as well as other) projects and the learning experience is ongoing


Fern, re your comments/questions:

1. Roger that; it's always helpful to re-use inf files known to work

2. the .raw format itself is a simple sequential grayscale format, nothing special. If you look into the folder of the file set I uploaded you'll find two .act files. These are color tables I made for working with .raw season files. So, say you load SEAK_seasons_04.raw. You know it's a 1-channel 257x257 so you load it as such into Photoshop. Image mode shows it to be Grayscale; switch it to Indexed Color mode then select Image > Mode > Color Table and load the seasons.ACT color table. You should see five colors show up in the index preview. Click OK and you should see the same color image as the corresponding SEAK_seasons_04.gif

Now the tricky bit for you is to find the cells in this 257x257 file that correspond to your airport area. In most cases you'd start with some georeferenced data, like roads or shorelines or a DEM, which makes it easier to locate yourself. In the absence of that you'll have to find your way by trial and error. Perhaps you could start with a dummy file that has a recognizable pattern, like alternating WI and HW cells. Compile this as a seasons file and then load it into TMFViewer. Place the airport outline on top and use the pattern to find your location. An alternative would be to do the math, i.e., coming up with a cell row/column position by dividing the lat/long difference between the NW corner and the airport by the span of a LOD10 cell.

3. That's correct. Once you've defined your cells of interest use the magic wand to select everything else and fill it with RGB value 254/254/254.

4. It's not the .raw file format but rather resample.exe that interprets everything with a value of 254 as "transparent" (like I said, I'm not entirely sure whether this works with seasons files).

5. No need to be afraid of the .raw file format. Once you've completed your edits with the season colors save the file as a gif image for visual reference then select Image > Mode > Color Table and this time load the Grayscale.act table. This will revert the colors back to an indexed grayscale format. The final step is to change the Image Mode to Grayscale and save the file in .raw format with "0" header bytes.

That's all; anytime you want to change the file load it, convert to colored indexed, do the edits, then re-convert to grayscale and re-compile.

Have fun!

Cheers, Holger

 

[scott967]

I've never tried using the 254 as transparent in a season file. It would make life much easier if it worked. I actually took screenshots of the default file in tmfviewer and used that as an overlay which is pretty low-tech. I use GIMP for image work and that doesn't seem to have a raw export, but does have something called PGM which will export raw, but with a very simple header. I just use a hex editor to delete the header and CR-LF at the end of each line and that does it.

FSX is much easier. If you look at the default file, it doesn't have any straight edges between seasons. I assume they used one of the options in FSX resample to do that but haven't experimented yet.

scott s.
.

 

[HolgerSandmann]

Hi Scott,

that process does sound a bit awkward but work-arounds are an FS developer's bread and butter

I usually start with a DEM in Global Mapper -- high-res is best but GTOPO30 will do -- and classify it into elevation bands that make sense locally for seasonal changes. I export it as .tif, transfer the georef information into the .inf file and use the tif as a base layer in Photoshop to construct the monthly seasons files.

The default FSX seasons file, IMO, is actually worse than the FS9 seasons file. It uses the same source data as the FS9 file but because they increased the resolution to LOD5/LOD13 (which is a good thing) they simply dithered the edges of the FS9 LOD10 cells to make it look less "square" (see screenshot comparison at CYYB below). From a real-world perspective the effect is awful because you end up with these single-cell seasonal flip-flops over a fairly large area. I call it the "shotgun" approach, the same issue as with the default blending masks (900/901) for vegetated and bare land class textures. Yuk!

The good news is that custom seasons files can be of LOD13 resolution and that the input file doesn't need to be .raw anymore or of 257x257 size; anything goes. The higher resolution makes my elevation-based approach much more precise and gradual changes of snowlines etc. can look pretty realistic now. See http://www.hsandmann.com/FSX/EF/EFX_Alpha_comp/EFX_Alpha_comp_seasons.html

Anyway, back to FS9...

Cheers, Holger

 

[Fern]

Painting the Gioconda was easier

Hi,

Ok, I am preparig my self for the big seasons attempt here.

Considering that workarounds are the FS developer's best friends (other than people who help at the forum, of course), I will also try to create the whole LOD2 bitmap in case the transparency 254 doesn't work.

Before I go for now I have to say my Photoshop is now showing what it should... Thanks, Holger. (Photoshop is not intuitive ...)

It will, probably, take me a couple of days to try all this. I'll be back.

Thanks, Holger and Scott!

Fern

 

[scott967]

In FSX geotiff works well. Some folks were complaining about Flroida, and I admit I can't figure out why the default seasons are set the way they are. I did a quick-and-dirty fix with just a little blending in the panhandle and it only took a very short while.

I have considered your elevation technique for setting fall in the US east. But I think to really make it nice you would need a weekly season map.

I haven't tried using the NSIDC daily snow cover data in FSX yet. In this case FSX has better resolution than the NSIDC 4km data so your elevation method would probably be needed to take full advantage of FSX resolution.

scott s.
.

 

[Fern]

Raw - difficulties

Hi, Holger and Scott

I'm back. I worked for several hours on this. I made some progress but I am not quite there yet.

1. I decided to do the whole LOD2 square that includes my area. I thought I'd have better chances of making it work than with transparency.

2. Using the TmfViewer and the Seasons.bgl file, I very carefully copied my entire LOD2 square onto a Paint window. For my month of April I have three colours in my LOD2 square: White, grey, and a bit of yellow.

3. Using Paint.Net I reduced the square from the big size I had created to the 257 X 257. As expected, the boundaries between colours showed intermediate tones.

4. Pixel by pixel I corrected all of the pixels (or so I think). To test this I flooded each area with a known color, such as Navy Blue, to make sure the entire area would show the colour, no little bits left with intermediate colours. Then I flooded the area again with the proper colour (White or Grey or Yellow (RGB numbers below).

5. Then I edited the grey/white portion of the bitmap that includes and surrounds my airport to make sure it was all white. This way that area would be all Hw rather than a mix of Hw and Wi in April.

6. Now I followed the following recipe (from Holger) to create my raw file:
* Open the 257 X 257 BMP with Photoshop.
* Saved as a GIF.
* Closed Photoshop, then opened the same GIF again(otherwise the Image>Mode>"Color Table" is greyed, inactive).
* Now I have the GIF image on Photoshop.
* Image>Mode>Color Table (this time it is active)
* Load, Grayscale.act
* My picture goes black. So far so good.
* Now Image>Mode>Grayscale. No change in the picture:still black.
* Save as raw, 0 header bytes. It gives me something about colour information being lost, I say OK.
* Looks like Holger's raw files (all black) BUT...

To test if my RAW is what it should be, I do the reverse:

* Open my raw file with Photoshop: Black square.
* Image>Mode>Indexed Colours - Still black square.
* Image>Mode>Color Table, Load, Seasons.act (from Holger)
* My picture doesn't show the original colors! Darn! The colours are all messed up, as per picture attached.

When I do this procedure with Holger's raw files I get the same as his GIF picture, with all the colours matching the GIF image and the TmfViewer image of Seasons.bgl.

My colours are all speckled, definitely wrong. Looking at the colours RGB numbers below I might thing the numbers could be wrong and that would be the source of my problem, but white is 255-255-255, grey is 150-150-150, and yellow might be wrong. However, even my white and my grey show completely wrong, speckled.

I am using the following RGB numbers for my colours, taken from Holger's gifs:

White 255-255-255
Grey 150-150-150
Yellow 255-241-0

Other colours I took from Holger's gifs (my LOD2 square doesn't have them):

Red 255-41-0
Green 0-221-97

I have attempted a several different things, such as go from the bmp to the raw without going through the gif first, and a few other variations on Image>Mode>Indexed Colors or Greyscale, but improvement: When I do the reverse, my coulours are all messed up. I try the process with Holger's gif (turn it into raw and back) and the become messed up as well. Then I tried just a 257 X 257 square all grey (150-150-150) with two rectangles inside, one white and one yellow (colours taken from the "seasons.act" table) and they give me the speckles, too.

Any hints on that, guys? Where am I goin wrong on this?

Thanks!

Fern

 

[Timmo]

I havent had time to read your full post so I may be off the mark here but: The RGB values you are struggling with arent actually RGB values par se....They are greyscale values (i.e. all three values in the RGB need to be the same...in effect it only uses one band/value between 0-255 for a grey scale ramp). Grey can be represented as an RGB value but of course when you convert to greyscale image, it effectively only uses one of the triplet of values.

At least for land and water class files, the input image is a grey scale...I havnt made new season files but presume they are the same.

Save as a greyscale tiff

 

[scott967]

My workflow goes like this:

I use tiff R-G-B image (should work the same as GIF). I edit using the colors green, gray, white, yellow, red, same as in TMFViewer (make sure any anti-aliasing etc is turned off so you don't get color blending). When the image is what I want, I then do a selection by color and bucket fill (in GIMP) with the required color substitution, i.e., 000000, 010101, 020202, 030303, 040404 so at this point the image looks black (but only season 0 Wi is actually full black). Then I convert the image to 8-bit grayscale (so the color values are now 00, 01, 02, 03, 04) and save as raw binary. I strip out the header bytes and CR-LF (which I get in GIMP, assume Paintshop has a different save file type available). You should be able to look at the resulting file in a hex editor and see that all the byte values are in the set 00..04.

scott s.
.

 

[HolgerSandmann]

Hi Fern,

when you talk about the image going "black" you have to keep in mind that it only appears to be black because the defined grayscale values in the file now range from 0 to 4, which is difficult to distinguish visually from black.

However, you can check on the defined values at any stage in the process by computing a histogram. Make sure that the image is at 100% zoom value, then select Image > Histogram. If you move the mouse across the histogram image you can read the pixel counts for the defined grayscale values (in your case, only levels 0, 1, and 4 should show any values) or, if you're working with the RGB color image, you can use the "Channel" drop-down menu to select the individual channels (R, G, or B) and check the presence of your desired values that way.

The "discard color information" warning will come up each time you switch from indexed mode (which is a 24-bit mode) to grayscale, which is a 8-bit mode. Therefore, clicking OK is the right thing to do.

It may be that this is a settings issue in your Photoshop. Can you attach your .raw image so that I can check that it's not to do with the image itself?

As Timmo has said, when converting an RBG or indexed image to grayscale, Photoshop has to compress the three 8-bit channels into a single 8-bit channel; only if the three values in the original channels are the same Photoshop can do the transfer correctly. That's why you need to load my Grayscale.act file first to prepare for the transformation: 255-255-255 becomes 0-0-0, 150-150-150 becomes 1-1-1, 255-241-0 becomes 2-2-2, etc.

If you're using the magic wand to select areas make sure that the anti-aliased checkbox in the Magic Wand Options tab is unchecked; otherwise you will end up with color gradations along the edges of the selected area.

In short, either your raw image isn't as "clean" as it should be (which I can check if you upload it) or it's one of the Photoshop settings that interferes.

Cheers, Holger

 

[Fern]

I can almost taste it

Hi, all

I think I had understood the "substitution" of the coulours from the RGB values in my GIF to the grayscale values 0,1,2,3,4, with the Grayscale.act, although I need more study on that. That should not prevent me from converting my GIF into a RAW that works, though.

I could not find "Histogram" under "Image" or any of the other menus. I have a little "Histogram" window, but when I run the pointer over the "navigation" tab picture, nothing happens.

Added a couple of hours later: I found the histogram/indexes and I had a litte trouble matching the indices you guys listed. My numbers were different. But trying to dig into it I found the following: If I open one of Holger's gifs, then load the grayscale.act, then immediately after I load the seasons.act, I get the same original colours back on the gif. If I do the same thing on mine, I get all the colours switched, what was grey is now yellow, and yellow turned grey, and white remained white. I then created a test gif, with four retangles inside of a white square. When I load the grayscale.act table, then immediately load the seasons.act table, the colours are all switched. Same colours, but white turns green, green turned red, etc. But it doesn't happen with Holger's gif!

I am attaching both my GIF (so you fellows can see what it looks like and that the colours are solid with no "bleeding") and my RAW (see note below) created with the following the steps:
* Image>Mode>Color Table, then Load, Grayscale.act, Load,OK
* Image>Mode>Grayscale, OK to "loss of color information",
* Save as... Paintshop RAW, Save.

NOTE: The "raw" file gave me an "Invalid File" error on uploading, so I changed the extension to txt. Please change the extension name to "raw" after you get it.

Plase keep in mind that I can open your RAW (Holger's) in my Photoshop and convert it back to its GIF format and see your colours. But when I try that with my RAW, I get rubbish, therefore I don't trust my RAW or the steps I am taking.

Here are the two files

Thanks!!!

Fern

 

[scott967]

I looked at your raw file, and it seems messed up. It looks like bytes of 00 and 01 are mixed like noise throughout the image. I'm operating outside of my comfort zone in image editing. Since GIF is an indexed color format, I'm not sure of the best way to simply substitute the indexes. I always convert images to either grayscale (8 bit) or R-G-B (24 bit) before editing.

scott s.
.

 

[Fern]

Able to go black and back to colours now!

Hi, Scott

I've been operating rigth at the edge of my comfort zone for a while, Hahahaha. But I am making progress.

Just this very minute I managed to get my GIFs to go "black" when I apply the Grayscale.act color table, and back to normal colours when I immediately after apply the Seasons.act color table. Major step forward for me. I accomplished this by entering in Pallet "Customise" and loading there the Seasons.act color table, and from then on my colours where indexed correctly, showing 0 for grey, 1 for white, etc., in the same order they appear in the Seasons.act table.

So, now I can apply the grayscale.act and back to seasons.act as many times as I want and the colours are good.

Then I create the raw. If I try to look at the colours in the raw file, now they are the right colours, but speckled. Here is what they look like now.

I'll keep trying. Thanks, but if you find anything, let me know.

I hope Holger has a hint or two up his sleeve yet...

Thanks

Fern

 

[Fern]

I'm almost there. I think.

Hi,

I hope Holger is "listening" and will come back for this one.

I got my raw to be created apparenlty correct. I now can create my RAW from my GIF, then open my RAW, it shows "black", then apply the Seasons.act colour table to it and the colours appear perfectly clean and with the proper RGB numbers (no deteriioration on the conversion to and from)

Before I go on to the next step (Create my seasons.bgl with Resampler) I'd like to ask Holger two questions:

1. I created the RAW without going Image>Mode>Grayscale. I saved as RAW straight from my GIF after I applied the Seasons.act table to it (colours still showing). After saving, I open the RAW again and it comes back "black", and Image>Mode shows "Grayscale", even though I didn't do it manually.

When I then change it to Indexed Colors and run the mouse pointer over it, it is still "black" but it shows the indexes where the coulours would be (Histogram/Information).

So, did I do this right or do I have to click on "Grayscale" before saving it? (That seems to be what puts the specks on my colours)

2. The colours index seem to be, according to the comparisson between Seasons.act and Grayscale.act,
Grey = 0
White= 1
Yellow= 2
Green = 3
Red = 4

Those are the numbers that show when I run the pointer over the picture, and it seems correct, but I think I saw different references in one of the previous replies.

Are those correct numbers?

I think that, if this is correct, it is time to go for the for the seasons.bgl.

Thanks!

Fern

 

[HolgerSandmann]

Hi Fern,

glad to hear you've got the .raw file creation figured out. What did you do differently for it to work?

As a "preamble": it seems that I got you confused a bit because of my reference to the .gif format. I really only do that (create a gif) to have a visual record of my individual months without having to load up Photoshop. You don't need to create those gifs if you don't want to; they are not part of the required process to generate the seasons file.

As for your questions:

1. Looks like you found a shortcut to my procedure I just tested this myself and it's true that you don't need to apply "grayscale.act" before saving the .raw. Actually makes sense too: given that only the first five values in the colored indexed files are defined they will automatically get translated to their grayscale equivalents when you save them as (8-bit) raw. Meaning, the index field with the grey color becomes "0", the white field "1", the yellow field "2", etc.

2. Those are the correct grayscale - color translations. Looks like you're ready to roll.



Cheers, Holger

P.S.: I did a quick test with placing some 254 values in my seasons file but I don't think it works. At least it shows in red in TMFViewer instead of the usual yellow for "transparent" cells. Haven't tried it yet in the sim though.