Thank you for sharing this. I've been playing around with it the last two days. I do have a question about calibrating my own filaments. I printed the calibration swatches, but I'm having trouble with the light source and getting good HSL values. I'm getting very different hue numbers based in the thickness of the swatch. For IIIDMax Fuchsia I used this image in which white is not really white and the color fildelity is terrible

I generated these values.

I noticed in your .json file, your hue and saturation numbers are very close together with lightness decreasing evenly with thickness. Did you measure these values, or estimate them? I've tried different light sources and color balancing the image, but not having much luck. I thought about using the manufacturer's value and then eyeballing the saturation and lightness values. Thanks for your help.

If I start with an image that is 2555x1739 pixels (300 pix/inch) in photoshop, and ask for a width of 216 mm, when I get the stl into bambu studio the aspect ratio appears to be off.

The PNGs look correct, however.

I see you have the option to create a Pixel Art image. Is it supposed to create an image that can be used to hand on wall, etc without light? If so I have had little luck with it creating the colors needed to recreate the file I was using. It mainly create a image with CMYK and nothing seemed 'mixed' to create the desired effect.

Here is the command I used:
java -jar /Users/jwhiteman/Documents/Projects/PIXEstL-0.0.9/PIXEstL.jar -Y -w 108 -H 134 -p /Users/jwhiteman/Documents/Projects/PIXEstL-0.0.9/8.json -f 0.24 -m .2 -b 0.12 -M 1.8 -tW .1 -cW .1 -z true -Z true -F FULL -d RGB --srcImagePath '/Users/jwhiteman/Documents/3D/_clipart/StainedGlass/Stained-Glass-Dragon-Background-84739800/1 (1).png'

Perhaps I am doing something wrong or I am not understanding what this feature does. I was hoping it worked similar to Hue Forge and performed the color mixing.

So I followed your instructions as best I could with the following caveats:

The STL’s didn’t match the written descriptions.

1- In the calibration discussion you mention a separate “square” at integer multiples of the print layer hieght (i.e. 0.10, 0.20, 0.30 and so on for a .10mm layers hieght). Yet the STL’s first “square” was 0.20 and the rest incremented by the 0.10 layer height. Is there a reason for the first one having double the layer height?

2 - While it wasn’t explicitly called out the separate STL (full length but a flat 0.10mm Z across the entire surface) appears to be designed to print under the stair step gradients and should be printed in white (gathering that from whatever slicer was shown there (I’ve never used anything but prusa slicer so was unfamiliar with the UI), so I’m assuming I have the correct assumption there.

Following the other comments, I decided to go the 7 layers of 0.07mm LH, and it dawned on me that that might change or need to be so I built a fully parameterized model in fusion that’s set up where you specify the number of steps, the square size, the target layer height for each step an an optional “first step addtional Z height” in case what I viewed with the demo calibration SLT really needed to be there. It also takes a separate “first” layer height for what I believe to be the “needed” white layer under the whole thing.

It then builds the steps and the ‘white’ base

I then set it up for 7 steps @ 0.07 @ 25mm square, with a 0.15 white first layeer under the whole thing. Exported that, and filled the need with IIIDmax’s light blue, yelllow, fushia, white and black.

I then printed those, and that led to the next question..

How do you calibrate measuring the colors? I’ve got a multi level LED panel with various white color temps (not sure on the exact values though as the manual is in Chinese) and variable brightness. I put the strips on that, took several photos at various color temps and brightnesses (noticing my iPhone camera auto compensated for the various brigntnesses, as all of them imported looking mostly the same).

What wasn’t clear at all was how to white balance this. I’ve done a ton of professional photography back in the SLR days and know how to pull a white balance there (I still have several neutral gray targets with specific color temp ranges) but this is a whole different beast, and being backlit makes the prospect of getting an accurate color balance a puzzle.

So what I ended up doing was importing them to photoshop, and noticed the “white” border around the strips was anything but. the Iphones’ auto compensate had rendered those various shades of gray.

So my next thought was to try to get the border white stuff back to white without importing a hue shift and just sticking to levels and brightness / contrast adjustements. That “sorta” worked.

The next thing was measuring the colors - even with ironing on some (particularly the whites and blacks) still showed the lines. My “sorta” solution for that was to run a Gaussian blur on the image, as it’ll change contrast and edge deltas but shouldn’t muck with the hue much at all and only diddle the saturation a little. It was either that or run an average calc on all the pixels in a selected area and the Gaussian blur was way less work.

Next i expanded the JSON color palettes to 7 layers for each color. What wasn’t super clear though, was where you pulled your hex HSL (least I think that first JSON parameter is HSL (hope it’s not RGB or I really screwed it up). So where does THAT first one come from? The middle of the spectrum of your swatches? The first? The Last? Does it even matter? that part wasn’t clear.

So I transferred over all the HSL values from color slurp (which if you’re on a mac is great for this sort of thing as you can create templates for the output format when you copy a value out of a pallete, whcih gave me the entire entry, pre formatted per your JSON layout in one go per color. saved a LOT of time.

So I updated the palette, added in my 5 IIIDMax initial filaments, and saved that with your jar and the other files to a directory and cloned the sample.bat file and started modifying that. What I noticed is that my hues and satruarations for the IIDMax counterparts for the CMY stuff was in the same ballpark, by L values were generally off from yours by a good 20 points in most cases. Ergo the question about what’s the best practice for both backlighting these and measuring them..

From there it was onto the batch file modifications.

The first thing I noticed is when you drop that on terminal (at least in Mac OS Monterey) the shell is expecting fully qualified paths for EVERYTHING, so I needed to drop the files one at a time on terminal to get those paths, paste that into the batch file and then applied your suggested settings for a 0.40 nozzle. I noticed there, that the default backing height at (0.24mm) wasn’t an even multiple of the 0.10 layer height, and the neither was the texture thickness default.

Thinking that having a non integer multiple of the layer height (particularly for the texture file might have an adverse impact I settled for 0.28 for the base (at a 0.07mm layer height) thus giving me 4 layers of backing, and a similar integer # of layers for the texture height (Cant’ remember the value but it was close to your suggested 0.4mm default, just rounded to the closest integer multiple of my 0.07mm layer height.

My source image was a 1200DPI color can of a magazine cover, which I cleaned up in photoshop (to ditch the offset printing Moire effects you get on a scanned print, some basic straightening, skew correction and my eyeballed color correction based on having shot some 200,000 or so posted photos over the years. I did a image resolution drop on that bringing it down to 300 DPI and that became the source image.

I bumped the color layers from 5 to 7, left the rest at defaults and let it rip.

I unpacked the zip, dropped all of em into PrusaSlicer (which asked if they were all a single file with multiple parts) and I answered yes, and it (apparently got the stacking order correct). Sent it to slice with 100% rectilinear infill and off the printer it went. At 130mm x axis (portrait orientation) this was a 13 hour print.

So here’s my source color pallete against the light pad ::

these were all the various (indecipherable chinese) color temp values of the backlight. the sometimes illegible squiggly marks on the swatches was due to my fusion model baking in the exact layer height of each swatch square so if I have multiples of these at different layer heights I’ll be able to tell which is which.

So here’s the print, again on the same backlit pad at various color temps and brightnesses.

Was pretty happy (very actually) with the detail, not so keen on the very white highlights on her face, and the color stuff is somewhat close but the TIME lettering and the non subject gray background is all over the map color wise.

So here’s some close ups of the details:

And the original source:

So, curious as to where I may have messed up, how I could better or more accurately handle the color palette sampling, and any other recommendations you might have as to how best use this thing.

Also, as I’m also a programmer, I could probably cook up a gui app for mac and windows that would handle the creation of the JSON Pallette by feeding the app the pix of the calibration swatches and picking the colors and cratering a library of sorts for the filaments, and the generate specific Pallette files using any subset of the filament libraries “sampled” colors to be saved as a preset, or applied to a specific image, and allow the user to use standard OS hosted input output dialogs for getting the source images and the designation image, and feed that all to your jar on behalf of the user. Shouldn’t be too terribly tough to cook up as you’ve already done all the heavy lifting.

Mesh files are significantly smaller. Thanks and keep up the good work!

I added a curve paramater to the image file to test it out, but it doesn't look curved when openeing it. Example: java -jar PIXEstL.jar -p filament-palette-0.10mm.json -w 130 -C 5 -i Cafe_Terrace_at_Night.jpg

Also there are double the files, one for layer 1 and the other for layer 2. Should I just load them all at the same time?

:-(

I think you will be better served by a different filament model which can eliminate the need for measuring different thickness. You can think of filament as having 2 components, an absorptive/scattering component and a coloring power component. The absorptive component is how much neutral light gets through, so a 1mm slice might be 90%. Then a 2mm slice is .9x.9=.81, you can calculate any thickness this way. The other is the "coloring power", there are several ways to think of it, but one way that can be combined with the scattering is by realizing that, for example, the yellow "power" of a filament isn't it's yellow reflectivity, it's the ability to absorb blue light. So yellow is actually "minus blue" and you can also give it a loss like the 90% example above, a 2mm slice has 19% yellow "power". Both of the numbers can be combined into, for example, 3 (CMY) or 4 (CMYK) channels that can produce pretty good results. The best results would be sampling every 10nm and measuring the transmission at each wavelength.

I was able to create my own 7 layer color profile of the 4 Bambu CMYK filaments. Printing 7 layers at .07mm instead of 5 layers at .1mm gives a good color blend and resolution. The quality is almost the same as a .2mm nozzle by using a .4mm nozzle with .3mm line width setting. Thanks for this awesome program!

removed

@gaugo87 - Can you please go into some detail about how the layers in the JSON file work. My understanding was that they corresponded to the color layer being printed but that does not seem to be the case. For example, I set a Gray filament to only have layers 1 and 2 defined in the JSON file.

"#8E9089":
{
"name": "Gray[PLA Basic]",
"active": true,
"layers": {
"2": { "hexcode": "#938C79" },
"1": { "hexcode": "#BAB8A3" }
}
},

But when I generate the STLs and load into Bambu Studio and slice, I see that Gray being used on color layers 6 and 7 (actual layers 7 and 8) when I expected to see those on color layers 1 and 2 (actual layers 2 and 3). I'm sure I must be over simplifying things and would really like to have a better understanding for future tuning of the palette. Also, what causes the preview that is generated to be so far off from the printed results in some cases?

Any detail with some examples would be great!

Thanks!
Greg

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

So I've been obsessing with the ability to print color-accurate lithophanes with only CMYK filaments over the last few months. I have created over 30 palette files using different methods to generate the HSL/HEX codes. After hundreds of prints and a lot of trial and error, here is a summary of what I've learned so far:

1. I'm using only CMYK colors from Bambu (CMYK bundle) and similar colors from IIIDMax (Fuchsia, Light Blue, Yellow and White). I am really focusing on only using 4 colors so that my lithophanes are printable by anyone with 4 color capability like a Bambu with AMS or with Mosaic Palette.
2. 7 Layers at .07mm layer height seems to work best for me. I've tested 5,6,7,8,9 and 10 color layers. I don't see much change in quality above 7 layers. .07mm layers are easily printable with Bambu printers and yield a color section close to .5mm thick.
3. I've started printing the color layers separately from the texture layer. Sometimes better quality can be achieved by printing the texture layer vertically. Flat vs vertical
   
   
4. I have found that color accuracy is very dependent on color-code selection and that no single palette is suitable for all types of lithophanes. Natural landscapes and photographs of people are the most challenging because you can instantly tell that a color is not correct.
5. I have tried various swatch types and various methods to measure the HSL values. Thanks to @gaugo87 for adding the ability to use HEX values in addition to HSL values. That has reduced the time required to generate a color palette. Initially, I explored various methods to analyze a picture of a swatch, but ran into many inconsistencies related to light source, white balance and pixel sampling. I'm convinced the camera in my phone does not always capture the true color.

Point 5 led me to invest in a (somewhat) inexpensive standalone colorimeter, thinking that I could measure actual colors with the actual light source. I've tested various swatch designs and settled on a swatch with a .15mm white backing layer and 10 successive color layers at .07mm. I was also able to test different light sources and different temperatures and intensities as well as just a white paper background.

These lithos were generated using the swatch on a simple white background with no backlight. Bambu CMY and IIIDMax White.

I have been really pleased with the results and have been focusing on generating palettes optimized for portraits of people and landscapes.

Tagging @dts350z and @ibgregr because I thought you might be inetersted.

I generated the STL files with following skript:
java -jar PIXEstL.jar -p filament-palette-0.10mm.json -H 150 -c 4 -l 4 -i IMG-20181225-WA0007.jpg
The preview image was displayed with the correct colors.
Ich folgte den Anweisungen in der instruction.txt Datei.
The wrong colors were used in the finished printout. There were also 36 layers created where hardly any light was shining through.