nanoDLP

Thank you for the feedback.

I agree having correct brightness will be helpful but we do not know range of values users will going to enter so until all square filled we could not display brightness correctly. Also I believe it will be confusing for the users. Instead I have made preview button display very fast to help measure correctness of values.

These are native html5 controls, It is not possible to modify them. I suspect your browser is not customized for 4K screen or something. Could you share screenshot, maybe we could play with size of box itself.

First plan was that, but these kind of algorithms are very slow on RPi, I already tried couple of different ways, but if you could provide pixel level implementation in golang we could try
Also as we place sensor by hand to take measurement, it will never be center of square so having algorithm working from exactly center would not make generated mask more realistic.

I have tested algorithm on amd64 before updating beta version. I did not expect it runs this slow on ARM. I have done some changes, now it takes under 30s to render mask. Also I have separated preview logic, so it prepare image without going through heavy optimizations.

I see you have not upgraded to the latest version yet
Your resizing idea is awesome.

Let me go through my assumptions and implementation.
User could enter any float (64bit) number, not just 1-256. Final result will be  0-255 grayscale image but I am not sure if all uv sensor reads value from 0-255. So to instead of forcing user convert value they read to 0-255 format, they can enter any value.
We find out lowest value and try to bring all brightness close to lowest value after they have filled whole grid. So user does not need to preview image at all maybe once just at the end of measurement to make sure everything is correct.

I think we have two different idea.
Yours
1. User scan whole surface to find out lowest value on the surface.
2. Measure the first point and try to adjust value to make it brightness match lowest value on the surface. Will do same thing for all other points.

Mine
1. User enter whatever her/his sensor reads into the grid, one by one.
2. At the end press preview to make sure nothing require adjustment by scanning surface with sensor

I do not have first hand experience in uv sensor usage so let me know which way is easier to use.

I hoped for linear reading. I will change the implementation.

Cool! This is getting there!

Here's some feedback:
* It threw me off a little that when you press enter in a cell it generates the mask. I finally realized I have to type a value and wait (without pressing enter) so the grid DLP cell changes without generating the mask. The up/down arrows are nice (just really small on my 4k screen)
* I like the blue outline, except is is really hard to see at full brightness (value=256)
* Can you persist/store the cell values? This would allow the user to go in/out of mask generator to do things like turn on/off projector w/o losing settings, or come back later to adjust settings a little.
* When the mask generates, it is "blocky" (ie not a useable mask) Do you have plans to use an image resize to create the mask?
* Nothing seems to happen when I click [save mask]. I expected it to change the mask on the Setup...Projector Mask screen.

I hope that is helpful!

Regards
Larry

@lcluff2000

May I ask what sensor you are using . With my UV sensor unfortunately I have no good experiences.
Since the DLP chip emits the light at a certain frequency,
the measurement results of my sensor at the same measuring point are very different.

It is 10% of pixel blur on sides. It is much more smooth than upsizing pixels. Are you sure we need more smoothing? My guess is difference should be normally around 10-15% from center to sides. So final result will be much smoother.

Here is the mask I generated with Nanodlp:

So I decided to see what this would look like with the resize algorithm... I followed this process...

Create a PGM file by inserting the values you entered into Nanodlp (make sure to have .PGM as the file extension)
test27.pgm.txt

Convert the PGM to PNG (select color=gray):
Use this URL: http://image.online-convert.com/convert-to-png
The image is very tiny right below this text

Resize to 1920x1080 (select png file from above, section 4 uncheck "keep aspect ratio" & enter 1920 & 1080, section 6 select PNG, section 7 select Lossless Compression, click [resize image] then [download image])
Use this URL: http://resizeimage.net/

Wow!  wow!  Guys this is great! I hope it's okay to glom on this thread and ask/inject some of my experiences on this...

I'm just starting to do the same mapping for my Viewsonic.  I started off doing measurements with the spectrometer from public labs. (https://publiclab.org/wiki/spectrometer)  With this I tuned in the projector settings allowing increased blue light shift that was a stable curve between 390-450nm.  (Because the UV sensor from spark is best up until about 390 (ML8511) - after which the sensitivity falls off rapidly).  It's probably best to choose a smooth curve over this area since most resins used for the DLPs cure at 405nm (or are at least targeted for this wavelength).  I'll go in and list those settings I found to be best for the curve in a separate message. 

I also made a mount for the UV sensor with measurement tabs on the sides to allow easier identification of where the sensor is being placed on the grid.  Again, if you guys are interested I'll post this handle in stl in a separate post.

Just to make sure I'm caught up with the journey thus far.  We are all trying to normalize the intensity of the UV across the mask.  The current method is to use the lowest value and reduce brightness on the other areas...I just wanted to ask, if we start with a brightness value of 20% could we not adjust up and down to make it easier?  If the lamp operates on a curve for intensity, a beginning default of higher brightness (50+) to start off might be adding to this polynomial solution of ^5 power and thus the error. 

I hope I'm helping...

Elliot

Thanks Larry-

Re: band pass- Would that work, I had thought of that.  But if the sensor cuts off at 390 it still doesn't register above that value...correct? 

Re: Stl I'll post shortly

Re:Brightness

So what I found is that with higher brightness settings in the viewsonic, even with high contrast, the bleed-out overcomes the contrast...black is not black anymore.  So high brightness affects other areas.  So what I'm trying to do is find the sweet-spot that allows reasonable curing times while having very good control over light transfer to other areas you don't want cured.  We have to assume that the light is being refracted as it enters through the glass and then the resin.  I'm starting to work with some lenses that allow better collimation of the beam without dispersion.  So if we get the filters on the viewsonic right, and have basically the highest tolerable UV band when black is black.  That's the sweet spot.  Then Start with brightness (lamp intensity) around 20-40% we should be closer to having a normalized projection.  Maybe I'm not understanding how the greyscale is being done...is this basically a contrast setting customized for different areas of the Ti chip?

Thanks!

Elliot

Elliot,
Re: bandpass - Looking at the curve for the sensor, the 405nm output will be about 20% of the output for 390nm, but there should still be an output. At least that is my hope.
Re: stl - Super! Thanks!
Re: brightness - I personally haven't played with brightness. I can conceptualize the bleedover situation you describe. I'm not quite sure how this maps to even UV intensity across the entire vat bottom? I think bleedover might be very local (millimeters) and lamp intensity is across the entire vat bottom (multiple cm)? The greyscale is being done by projecting the mask verses just a blank white rectangle. Any time a slice is projected it does a boolean AND of each pixel on the mask with each pixel on the slice. The mask is created by the method described in prior posts. I'm no expert at this stuff, so hopefully this is making sense...

Regards,
Larry

Right- So on the band pass- this is why I was going for the smoothest curve over the range.  (I'll post some of the spectrum tomorrow or next week - getting late here!)  My thoughts were if it was a stable line and equal between 390 and 405 - then I don't need a band pass.

So I think what's happening is contrast plays against brightness - to a point - and then one can supercede the other if it's a large difference - like 10% vs 90%.  I believe the greyscale is contrast/brightness - but maybe someone else can chime in here.

I mean  this

Last edited by DLprinter (2016-08-22 13:51:50)