DIY 31 Megapixel Enlarger

Ethan Brossard said:

My screen is working fine now, so eventually yours should go back to working. When mine got burned in, I think I had it running for 12 hours or so unattended, and I think it took a couple days to get the effect to dissapear.

Click to expand...

Yeah it's strange, when I do these exposure tests it's only getting a maximum of about 45 minutes operation with the image displayed, then I turn it off.

This ghost effect would be pretty catastrophic in their intended use (SLA 3D printers) so I wonder how they avoid it? I'm thinking that the exposure time of each layer is probably only a few seconds and they probably blank the screen between each exposure, so the constant cycling of pixels might prevent them from getting stuck.

I could probably implement this in my code too, just have the screen flash to black and then back to the image every 5 or 10 seconds during the exposure. It would increase the exposure time, but not by a huge amount of the black screen is only displayed for a fraction of a second.

I’m guessing in SLA printers since each layer is a different shape no single frame gets displayed for a long enough duration for it to burn in. I made a gif which flashes between black and white that I set to full screen whenever I’m not exposing, and since creating that I’ve not had any issues with it burning in again.

AndrewBurns said:

Yeah it's strange, when I do these exposure tests it's only getting a maximum of about 45 minutes operation with the image displayed, then I turn it off.

This ghost effect would be pretty catastrophic in their intended use (SLA 3D printers) so I wonder how they avoid it? I'm thinking that the exposure time of each layer is probably only a few seconds and they probably blank the screen between each exposure, so the constant cycling of pixels might prevent them from getting stuck.

I could probably implement this in my code too, just have the screen flash to black and then back to the image every 5 or 10 seconds during the exposure. It would increase the exposure time, but not by a huge amount of the black screen is only displayed for a fraction of a second.

Click to expand...

The problems they met in 3D printing can be seen in this video:
TL;DR: The first layer printing takes too long time, and the heat from resin curing cannot dissipate, making the screen more prone to burn-in with fixed image at high temperatures.

Although your machine doesn't directly cure resin on its surface, it has significantly higher UV power and runtime than typical 3D printers(350w vs 50w, 1000s vs 50s), while the LCD screen absorbs over 80% of the UV power. I know you've measured the temperature, but I'm still concerned about whether some localized heat points may appear and pixels might overheat. Maybe you can try not only have the screen flash to black(now they absorb all the UV power!), but also cut off UV LED for a while.

Yezishu said:

The problems they met in 3D printing can be seen in this video:
TL;DR: The first layer printing takes too long time, and the heat from resin curing cannot dissipate, making the screen more prone to burn-in with fixed image at high temperatures.

Although your machine doesn't directly cure resin on its surface, it has significantly higher UV power and runtime than typical 3D printers(350w vs 50w, 1000s vs 50s), while the LCD screen absorbs over 80% of the UV power. I know you've measured the temperature, but I'm still concerned about whether some localized heat points may appear and pixels might overheat. Maybe you can try not only have the screen flash to black(now they absorb all the UV power!), but also cut off UV LED for a while.

Click to expand...

Yeah I thought that screen temperature could also be a reason that I see this issue faster than people using the same screen for normal enlargers with far less optical power.

I did measure temperature on the LCD using a thermocouple during development and I've aimed to keep steady-state temperature under 70 degrees Celsius. One difference with my setup vs. a standard SLA printer is that I have an enormous amount of cooling air blowing over both sides of the LCD screen constantly during operation (without that, the LCD would overheat and fail within seconds I suspect).

I'm not convinced that a black screen will get appreciably hotter than a completely 'clear' screen. You have to imagine that the maximum transmission of UV light through these LCD screens is <5%, that means even when the screen is completely clear it still absorbs 95% of the light energy hitting it. So the difference in heating of a completely black screen vs. a completely clear screen is less than 5%.

I could turn the LED on and off during operation, which I suppose would just reduce the average power and thus average temperature of the LCD during operation (resulting in longer exposure times but at a lower temperature). In some ways this is functionally the same as running the LED at a lower continuous power, which I can also do as it's connected to a variable constant-current power supply. One difference in operating at a higher peak power with some cool-down time vs. operating at a continuous lower power is the higher peak-power operation should be better for processes that have non-linear sensitivity to light (like DAS sensitised gelatin, which hardens via a two-photon process and benefits substantially from higher exposure power over shorter times).

Ethan Brossard said:

My screen is working fine now, so eventually yours should go back to working. When mine got burned in, I think I had it running for 12 hours or so unattended, and I think it took a couple days to get the effect to dissapear.

Click to expand...

Seems like I finally managed to get the ghost image to go away, the key seems to have been running the LED at full power into a black screen for 30 minutes or so. I read online that the persistent image is indeed made worse by the things I suspected (heat, high-contrast images) and so heating up the screen when trying to get rid of the persistence made quite a difference. It also makes sense why for me it happened relatively rapidly while for you it took extended 'on' time, your screen wouldn't be getting anywhere near as hot as mine.

Now that it's gone I'll have to implement periodic screen blanking and turning the LED off and on during exposures to prevent it coming back again.

I have not spent much time on this project recently, and when I do, I don't have that many minutes to spend. I managed to get an okish linearization curve using chartthrob, and with the help of Claude Code modified it to generate pencil curves (.AMP files) that allow 256 values. I struggled with light falloff issues messing up calibration charts, and thought I might get more controlled correction curves if I modeled them as a 2.2 gamma correction component, a contrast component and an offset component.

Then I realized I was wasting my time throwing my efforts into a closed Adobe ecosystem, and made my own python tools to make charts and manipulate curves, which became its own distraction for a while, but I've just published it in its current state so I can move on and work on improving my printing workflow. I posted the link in a new thread:

I guess next steps for me are an expose program 'cos I'm still using the one @avandesande wrote, and while it works great, I can't change it to my own taste. I've not done much research. I use OpenCV for my chart program. SDL2 came up when I searched a long time ago. If I just want to display 1 image for a certain number of seconds, probably anything will work, but I'd like something that can display lots of large images for a precise number of frames, that must start to get tricky as hardware requirements are lowered. If anyone has pointers or code they're willing to contribute under a GPL license, please speak up. You might save me or others some effort.

I could post the improvements to chartthrob if there's interest, but it's nothing substantial. it can make pencil curves, and it reads sample by using median instead of mean.

Graham06 said:

I have not spent much time on this project recently, and when I do, I don't have that many minutes to spend. I managed to get an okish linearization curve using chartthrob, and with the help of Claude Code modified it to generate pencil curves (.AMP files) that allow 256 values. I struggled with light falloff issues messing up calibration charts, and thought I might get more controlled correction curves if I modeled them as a 2.2 gamma correction component, a contrast component and an offset component.

Then I realized I was wasting my time throwing my efforts into a closed Adobe ecosystem, and made my own python tools to make charts and manipulate curves, which became its own distraction for a while, but I've just published it in its current state so I can move on and work on improving my printing workflow. I posted the link in a new thread:

Open source tools for curve and test chart manipulation

I have made a few tools for manipulating digital negative curves, images and test charts while working on my lcd enlarger (lcd thread: https://www.photrio.com/forum/threads/diy-31-megapixel-enlarger.197305/ ) There is an Adobe ACV curve, AMP pencil curve and CSV cmdline manipulator, and a...

www.photrio.com

I guess next steps for me are an expose program 'cos I'm still using the one @avandesande wrote, and while it works great, I can't change it to my own taste. I've not done much research. I use OpenCV for my chart program. SDL2 came up when I searched a long time ago. If I just want to display 1 image for a certain number of seconds, probably anything will work, but I'd like something that can display lots of large images for a precise number of frames, that must start to get tricky as hardware requirements are lowered. If anyone has pointers or code they're willing to contribute under a GPL license, please speak up. You might save me or others some effort.

I could post the improvements to chartthrob if there's interest, but it's nothing substantial. it can make pencil curves, and it reads sample by using median instead of mean.

Click to expand...

When you say light falloff - do you mean the enlarger is not illuminating the full ‘negative’ evenly?

Yeah. Maybe it's my enlarger lens, or I have the the negative tray the wrong height from the bulb or the enlarger bulb is not evenly illuminated, or the lcd itself is uneven or many of the above. Look how fuzzy the attached response curve is. It's quite easy to make a good linearization curve from that. Each the neighbors of a grey level in the ramp are chosen to be quite far away on the chart. If I had used a linear ramp, the response would wiggle up and down at a much lower frequency, making it harder to find a good linearization.

I need to make a light falloff correction map too, which will help, but it is not that bad and I'll do other things first. Today's task is making my chart tool apply a correction curve to a test image and add a step wedge with blocks with image black and white, and absolute black and white.

Now that I've got the distraction of publishing my curve tools out the way, I can get back to actually using them. I had been inverting my charts before I printed them, and if you do that you can't really divide out a gamma response ( you can, but you have to model the inversion too) I made a chart without inverting it and the part that remains is very straight for multigrade paper except for a gentle toe and shoulder. (I have inverted and non-inverted chart scans included in my tools release as examples) Next goal is to eliminate Photoshop from the workflow, and after that expose images with my own code.

When we encountered the vignetting issue (borrowing from photography), since the projected image was quite small than a full-frame sensor—we just put a CMOS image sensor and ND fliter there. With some code to calibrate the correction mask until the measured light intensity was uniform.