Color Mapping Problems

[dts350z]

First off, thanks so much for the PIXEstL program!

Based on the potential I bought a 2nd AMS, and all your recommended filaments, for my X1C. My goal is to create photorealistic color lithophanes from my astrophotography images.: https://www.astrobin.com/users/dts350z/

I've spent two weeks and lots of prints but I'm pretty much stuck. I can get OK results with this image: https://www.astrobin.com/full/3p6qyt/0/ although the colors do not match and the dark areas are not as dark as in the original.

Where I'm really stuck is with this image:

https://www.astrobin.com/full/2dzpgz/0/

Where the colors are way off and the only way to get the "black" sky was to modify the input image to replace any color close to black, with black.

As I said I am using the recommended Bambu filaments, with the exception that I found SunLu PLA+ White -m 0.08 -M 3.52 is best for texture, so I use that for white in the color layers as well.

I have also tried substituting PolyLite Grey for black, for the Nebula picture, but went back to Bambu Black for the galaxy.

I printed 7 layer (plus base) calibration tiles and sliced with the layer heights I'm using: -f 0.16 -b 0.08. I am using the System 0.08 high quality process, with ironing, 100% infill and no top or bottom shells for the calibration tiles, and the same settings (minus the ironing) for the color layers of the Lithophanes. I am printing the color and texture separately, during my color experiments.

Here are my calibration tile results:

Calibration Tile Results.zip

and my resulting palette file:

filament-palette-0.08mm 1 layer 8 filaments GCN.json

By the way, I tried using hex values for the colors in the palette file, but I couldn't get your program to run without error, even when json validators said my file was OK.

D:\Glenn\Downloads\PIXEstL-0.3.0>java -jar PIXEstL.jar -p "D:\Glenn\Downloads\PIXEstL-0.3.0\filament-palette-0.08mm 7 layers 8 filiments GCN.json" -f 0.16 -b 0.08 -w 144 -tW 0.2 -cW 0.2 -l 5 -m 0.08 -M 3.52 -d RGB -i "N:\AstroPics\NINA\Bode's Galaxy\Bode's Galaxy copy 144mm x108mm copy Replace Color for Black fixed Hue Color Replace Gray with Black.jpg Palette generation... Exception in thread "main" org.json.JSONException: JSONObject["1"] is not a JSONObject (class java.lang.String : 4a93e8). at org.json.JSONObject.wrongValueFormatException(JSONObject.java:2910) at org.json.JSONObject.getJSONObject(JSONObject.java:782) at ggo.pixestl.palette.Palette.(Palette.java:65) at ggo.pixestl.generator.PlateGenerator.process(PlateGenerator.java:32) at ggo.pixestl.Main.main(Main.java:12)

So I gave up and went back to HSL (I'm using the color picker in photoshop to get the color values from the calibration tile results photo).

Anyway I think there must be issues with the palette//color mapping, based on the following.

Try this calibration image:

Each of the stripes of color were color picked directly from my above calibration tile results (layer 7) in photoshop. So they should result in 7 layers of that filament color only).

The bottom most stripe is just a gradient from white to black. Then there is a gradient on most of each color stripe, leaving the leftmost part alone. I can provide the photoshop file I used to create that if needed.

You can see in the color preview that there are issues:

and the print result is even worse (color layers only):

D:\Glenn\Downloads\PIXEstL-0.3.0>java -jar PIXEstL.jar -p "D:\Glenn\Downloads\PIXEstL-0.3.0\filament-palette-0.08mm 7 layers 8 filiments GCN.json" -f 0.16 -b 0.08 -w 144 -tW 0.2 -cW 0.2 -l 5 -m 0.08 -M 3.52 -i "N:\AstroPics\NINA\Bode's Galaxy\Color Cal 144mm x108mm copy 2.jpg" Palette generation... (653 colors found) Calculating color distances with the image... Nb color used=175 Generating previews... Generating STL files... Layer[0.0] :Black[PLA Basic], Cyan[PLA Basic], Matte Sakura Pink[PLA Matte], Beige[PLA Basic], Magenta[PLA Basic], Matte Ice Blue[PLA Matte], Yellow[PLA Basic], White[PLA+ SunLu]

GENERATION COMPLETE ! (32543 ms)

Calibration Image printed results.zip

both in that the basic colors don't match the filament/calibration tiles, and that the colors mapped to lower luminance values are different from the original color.

Another side note, It seems that the color layer is meant to include luminance information, in addition to that in the texture layer, which is different than how other color lithophane generators work (colors all having the same luminance values, and leaving the luminance work to the texture layers). That's fine, and I may need that to get a good full contrast range in astroimages, but the colors should be right.

Maybe we need an option to tell the program what filament to use for luminance, be it black, grey or silver, and the program would then only use that filament, to change the luminance value of other filaments or color layer combinations. i.e, as Cyan get's less bright, it doesn't turn green, etc.

FYI I have done a lot of experiments, RGB instead of the default method, different numbers of layers in the palette files (even down to one) and different -l values in the program (between 3 and 8), but no joy.

Am I missing something?

Thanks

[dts350z]

-F FULL ignores palette entry with "#000000":

Also you don't get an instructions file with -F Full

[ibgregr]

Your palette file does not look right to me. For example, you have the following for Cyan:

"#0086D6": { "name": "Cyan[PLA Basic]", "active": true, "layers": { "1": { "H": 212, "S": 66, "L": 88 }} },

If you are going to print in 7 laters, you should have layers 1,2,3,4,5,6, and 7 with the HSL values for each layer from your calibration print so that you can have 7 different hues for Cyan but you only have 1. Same goes for the other filament colors. I have found that you have to get those values fairly close as it has a HUGE impact on the printed results. The calibration process is a bit hit and miss as it is subjective to the person doing it. Also, the camera you use and the monitor you use can skew the results as what you see on the screen may not match the printed results. I spent the better part of 2 weeks tweaking, recalibrating, etc to get a single image to print to my liking. Now I need to take a different image and see if I get similar results but just haven't had time. Another thing I found is that it helps to enable colors in your palette file that match what is in the image. For the image I was printing, I disabled Magenta but enabled Red as I could not get the color I wanted with blending. I have 2 AMS units so I enable up to 8 colors that fit the color scheme of the image.

Bottom line for me was....I had to get the calibrations set to get the colors I expected. I then had to do some slight editing of the phone (brightness, saturation, etc) and I finally got an excellent print. Also, while I love the idea of having this standalone program to do these color lithophanes, I also have used lithophanemaker.com (https://lithophanemaker.com/Color Lithophane.html) and it generates excellent results. As a matter of fact, I was using a print from that site as my gold standard when trying to get PIXEstL working to my liking.

Anyway...that's just my experience and $.02 worth.

[dts350z]

Thanks. I have run so many experiments, including one layer in the filament file, that I may have sent the wrong one.

Here is my 7 layer filiment file:

filament-palette-0.08mm 7 layers 8 filiments Gray GCN.json

FYI I am using an iPhone 8 for photographing the calibration tiles, and the tiles are in the Bambu Labs lithophone frame, so are using the same light source as the final lithophane. I didn't do any white balance operation because it seemed to me that with the lithophane frame I don't have any true white or other reference, as even the light from the LED panel is shown through a white filament panel. Perhaps I should tweak the white balance until what I see on the screen matches the filament color (but that assumes my monitor is correctly calibrated)?

It'd be great if you had time to run your program, with your filament file on my test image, in any case.

Since we are using the same filaments, would you be posting your latest filament/palette file?

[ibgregr]

Ok...here is my example....

Original picture:

And here is my printed result after MANY prints and palette tweaking (it looks better in person that it does when I took this picture of it with my phone):

And here is the palette file I used:

my-palette.json

The command I used to generate the lithophane was:

java -jar ./PIXEstL.jar -f 0.20 -b 0.10 -w 144 -i eastpoint.jpg -o eastpoint.zip -p my-palette.json -l 7 -t 900 -T 900 -Y -cW 0.4

That is using 8 colors (only the ones set to "true" in my palette file) and 7 color layers. And I chose the colors that I did based on the colors in the photo.

I hope that helps you a bit. As for using my palette...I hope it works for you. I would have thought the palette file packaged with the app would have worked for me since I'm using Bambu filament but using that palette with the 5 default layers did not produce results that were even remotely acceptable. The colors were way off. One thing I forgot to ask...did the preview photo look anything like what you expected?

Here is the preview that mine created and you can see it is very close to what I expected:

Oh...and here are my calibration swatches:

Magenta, Cyan, Yellow, White:

Ice Blue, Sakura Pink, Scarlet Red, Beige:

Misletoe Green, Latte Brown, Grass Green, Mandarin Orange:

I kept the default values and layers for black. I also kept the defaults for Silver and Purple as I did not have those at the time I was doing calibrations...and...I was not using those colors in this print.

One last thing...I'm not java developer by any means but have done coding (C, C#, python, etc). I made a couple of simple tweaks to this program. Since I was running this many times with different palettes, parameters, etc I would end up forgetting what I had tried. So I added code to:

1. add the command line parameters I used to the instructions.txt file
2. added the palette file that was used to the zip file. I did this as I was tweaking it quite often and wanted to be able to fall back to something that was working better than what I currently had.

I thought about going and adding the original photo to the zip file just so it would be a complete "package" but just never went back to figure out how to do that part. But having the command line parameters as well as the palette file used was a huge time saver...and saved me when I inadvertently removed the wrong palette file. :)

[dts350z]

Thanks! That's a beautiful result!

I will definitely check out your Palette file and compare the calibration tiles.

The program changes sound good. I am only a hobbyist programmer in various scripting languages and c/c++-ish. so I know the feeling.

What I tried here, today, since my monitor isn't calibrated, etc. was to set the layer 7 HSL, in my palette file, so the H = the hexcode as provided by the manufacturer (by the way in doing that I noticed that some the Hex values in the stock json file don't match what Bambu has published). Then I adjusted the H values of all the other layers by the "offset" I had in the H value in layer 7, so kept the S and L values and only changed H.

That got me a lot closer: filament-palette-0.08mm 7 layers 8 filaments based on filament hex GCN.json

And I applied the same manufacturer hex codes to my calibration file:

And here the Color preview results with these parameters:

java -jar PIXEstL.jar -p "D:\Glenn\Downloads\PIXEstL-0.3.0\filament-palette-0.08mm 7 layers 8 filaments based on filament hex GCN.json" -f 0.16 -b 0.08 -w 144 -tW 0.2 -cW 0.2 -l 8 -m 0.08 -M 3.52 -i "N:\AstroPics\NINA\Bode's Galaxy\Color Cal 144mm x108mm Colors based on filament Hex code.jpg" Palette generation... (3679 colors found) Calculating color distances with the image... Nb color used=744 Generating previews... Generating STL files... Layer[0.0] :Black[PLA Basic], Cyan[PLA Basic], Matte Ice Blue[PLA Matte], Matte Sakura Pink[PLA Matte], Magenta[PLA Basic], Yellow[PLA Basic], Beige[PLA Basic], White[PLA+ SunLu]

GENERATION COMPLETE ! (89029 ms)

So maybe I'm down to just a few "off" layer entries in the palette file? I'm not sure how to identify which ones are "off", however, other than looking for patterns in the layer to layer changes.

I'll try with your file, before diving in any deeper.

[dts350z]

Your palette file, just with the CMYK colors active:

java -jar PIXEstL.jar -p "D:\Glenn\Downloads\PIXEstL-0.3.0\ibgregr -palette.json" -f 0.16 -b 0.08 -w 144 -tW 0.2 -cW 0.2 -l 8 -m 0.08 -M 3.52 -i "N:\AstroPics\NINA\Bode's Galaxy\Color Cal 144mm x108mm Colors based on filament Hex code.jpg" Palette generation... (4307 colors found) Calculating color distances with the image... Nb color used=633 Generating previews... Generating STL files... Layer[0.0] :Black[PLA Basic], Cyan[PLA Basic], Matte Sakura Pink[PLA Matte], Beige[PLA Basic], Magenta[PLA Basic], Matte Ice Blue[PLA Matte], Yellow[PLA Basic], White[PLA Basic]

GENERATION COMPLETE ! (98279 ms)

Best result to date! Thanks!!!

[dts350z]

Oh, and by the way, have you noticed that the l parameter actually gives you one less layer of color that you specify?

• l7 gives one white base layer and 6 color layers. etc.

[ibgregr]

TBH...I had not really paid attention to the fact that I was only getting 6 color layers. I just read the other threads on here and those 2 guys were using -l 7 so I just followed suit! LOL. I want to get back to working on this soon. My next test is to take a totally different photo that has some different colors in it and see how close my palette gets me. I hope to one day be able to have a good solid palette and can just pick the 8 colors (as I have 2 AMS units) that closely match that photo and have it print with acceptable results. And, I have some more filament colors coming that I will need to do these calibrations on. Let me know how you make out with this. I'm glad to see that it was not just me fighting with this. I wish I could just give it the base color of the filament and maybe the "transmission distance (aka HueForge)" and this app would figure out what would happen as you layer the colors. Then the calibration would no longer be needed.

[dts350z]

Yes I as well have more colors. eSun PLA+, which was supposed to be amazing for texture but I didn't like the results. I am using this fisheye photo for comparing texture settings:

(at 45mm wide)

As well as Bambu PLA Basic Gray and Silver, either for texture or Gray layers. Crisp Lithophane Gray AF PLA for texture (not here yet). I also have all the transparent Bambu PETG colors, but have not tried them in a lithophane yet.

I too have 2 AMS units.

Please keep me/us posted as you add colors as your palette calibration is great!

I've also wondered about the "TD" Measurement. They are selling a kit that you just stick the filament in and it gives you the TD, but it seems you need a subscription to use it? It's not fully released (last time I looked), so maybe it will be a fixed cost. But yeah Hexcode + TD plus layer height ideally would be inputs to the program.

[dts350z]

@ibgregr I see you have -b 0.10. Were your calibration tiles printer at first layer 0.20 and layer height of 0.10?

What size nozzle are you using (I'm assuming 0.2, from the layer height)? I am waiting for my Panda Revo hotend and nozzles to arrive. The smallest will be 0.25.

[ibgregr]

I am using the .4 nozzle. And when I print a lithophane I do the initial layer at .20 and then .10 layers

The calibration tiles were printed with a .10 initial layer and then .10 layers. I guess in theory I should've used a .20 initial layer on those as well...not sure why I didn't. But the results are working so I'm afraid to change my workflow. LOL

[dts350z]

I added a gradient to my texture test pic, and spend the morning testing different filaments and settings:

I'm still preferring the SunLu White PLA+. The Bambu White has a yellow/brown cast. The AF Crisp Lithophane Gray filament arrived today, but like the PolyLite Gray, and the eSun White PLA+, by the time you get the max setting low enough, you only have like 16 layers/brightness. I'm going with the seetings/filament in the middle. Smooth gradient/levels (48) and good and dark.

[ibgregr]

The only issue I see with using -m 0.1 -M 4.8 is that your lithophane comes out to about 5mm thick. If you are going to design your own frame then that's not an issue but if you try to use any of the ones from MakerWorld then you will have some issues. The frame I'm using has you slide the litho into a slot and I think it will only fit up to about 3mm. But again, if you are designing your own then it's not an issue.

[ibgregr]

@dts350z Here is a copy of my current filament list. It has alot (but not all) of the Bambu Basic and Matte PLA colors. I used all hexcodes this time as it saves alot of time generating the file. I also removed the entry for Black as it is way to heavy handed in my opinion. So now if I need black I end up using Gray...or just let it figure out how to make a "black" with the colors at hand. You will also see that I only included 3 layers for Dark Brown[Matte] as anything thicker than that did not let any light through (similar problem to Black). I also guess I don't quite understand the layer numbers in the json file. For example, the Black entry had a layer 4 and 5 only. I took that to be that it would only lay down black on the 4th or 5th color layer but that is not what I see. So I would like to have a better understanding of how those truly work. If I could control the black to only be a single thin layer then I can see the benefit of having it. But the way it works now it gives me no value.

On you comment about the number of color layers. I do not exhibit the issue you stated. If I give it "-l 7" I get the base layer (layer 1) as white, and then the next 7 layers (2-8) has color being laid down, then from layer 9 on it's the texture being added. The way I could see this was in Bambu Studio, after slicing, I use the slider on the right and bring it all the way to the bottom (layer 1) which is white, and then as I go up each layer from there I see color being added through layer 8. So not sure what you are/were seeing.

Anyway...here is the file: bambu.json

Let me know how it works for you!

Greg

[gaugo87]

Hello

I sincerely advise you to reduce the number of layers. The program doesn't handle transmission distance. So, the more layers you add, the more inaccurate the preview will be.

For me, the main advantage of using 7, 8, or 9 layers is for people who only have 4 filaments because it allows creating light shades by multiplying the number of thin layers.

But if you have 2 AMS, I recommend sticking to 5 layers (where the transmission distance is "more negligible"). And manage light shades with clear filaments.

[ibgregr]

Hello

I sincerely advise you to reduce the number of layers. The program doesn't handle transmission distance. So, the more layers you add, the more inaccurate the preview will be.

For me, the main advantage of using 7, 8, or 9 layers is for people who only have 4 filaments because it allows creating light shades by multiplying the number of thin layers.

But if you have 2 AMS, I recommend sticking to 5 layers (where the transmission distance is "more negligible"). And manage light shades with clear filaments.

I am currently redoing my calibrations and will create one file with 5 layers and one with 7 and see what kind of results I get. This is an awesome program and I hope to get to the point where I do not really have to tweak the photo before running it through this. It would be neat if we could do like HueForge and provide the base color and TD and you magically figure out the layers and do away with this calibration. :)

[gaugo87]

For the lithophane mode, transmission distance (TD) doesn't matter much when the number of layers is low. So, I didn't focus on it much: the results were already very good without needing to manage it.

However, transmission distance becomes significant for a "painting" mode (like hueforge) or for the lithophane mode with many layers.

When I have the time and motivation, I'll take a look...

[ibgregr]

For the lithophane mode, transmission distance (TD) doesn't matter much when the number of layers is low. So, I didn't focus on it much: the results were already very good without needing to manage it.

However, transmission distance becomes significant for a "painting" mode (like hueforge) or for the lithophane mode with many layers.

When I have the time and motivation, I'll take a look...

No worries my friend! This is still an excellent program. I definitely look forward to your "painting" version as HueForge is just one big frustration to me!

[dts350z]

Thanks to all for the additional info and palette files!

On the TD thing, FYI I did spend a couple of days trying to predict L, based on TD and the orginal HEX from the manufacturer and I have a very messy spreadsheet that could be shared. It is giving a lot of numbers that are close to the calibrations tiles for some filaments, but others are 25% or more off.

If anyone is interested I will try to clean it up and or just post the formula

Hue and Saturation look to be even more difficult./ less well correlated.

[dts350z]

oh, and -l 8 gives me 7 layers in the slicer (not 8), anyway you count. The "elle" argument only matches the number of layers in the slicer if you include the base stl file (but still only 7 layers of color).

No idea what I am doing different, but here is my latest list of arguments.

java -jar PIXEstL.jar -p "D:\Glenn\Downloads\PIXEstL-0.3.0\ibgregr -palette Beige -20L GCN.json" -f 0.20 -b 0.10 -w 144 -tW 0.21 -cW 0.4 -l 8 -m 0.1 -M 4.8 -i "D:\Glenn\Pictures\Square format astro\The Tadpoles square.jpg" Palette generation... (4880 colors found) Calculating color distances with the image... Nb color used=1053 Generating previews... Generating STL files... Layer[0.0] :Grey[PolyLite], Cyan[PLA Basic], Matte Sakura Pink[PLA Matte], Beige[PLA Basic], Magenta[PLA Basic], Matte Ice Blue[PLA Matte], Yellow[PLA Basic], White[PLA+ SunLu]

GENERATION COMPLETE ! (55603 ms)